We understand cybersecurity incidents as any event that can harm a system’s confidentiality, integrity or availability. Cyberattacks are becoming more frequent and powerful, and what we observe is that companies are becoming primarily concerned with understanding how to react when said attacks occur. But this approach might not be the best. The breaches take place when a threat can exploit a system through its vulnerabilities or lack of safeguards. Thus, a combined effort of prevention, monitoring, detection and response can help us better protect our organizations.
As shown in the 2019 Cost of a Data Breach Report from IBM , the average cost for every record lost is $150, and the average cost for a data breach is $3.900.000.
The following are some tips and best practices to deal with cybersecurity incidents:
As we have seen, a breach occurs when an agent is able to exploit a system’s vulnerability. Said intrusion can result in substantial economic costs as said earlier, which can threaten the financial stability of the company; thus, it should be the main priority to identify and amend those vulnerabilities in order to prevent such breaches.
Some of the actions that can help a company prevent security incidents can be:
- Doing system backups and testing its integrity, which can help restore the systems in case an incident takes place
- The monitoring of the network to detect deviations from baseline by documenting the baseline
- The centralization of logs
- The correlation of events
- Keeping the team informed about information security
- The creation of a Computer Security Incident Response Team, also known as CSIRT. This team would deal in a documented way with incidents by supervising, communicating, registering, reviewing systems, increasing cybersecurity knowledge, investigating new cybersecurity strategies, reducing risks, raising awareness, planning system recovery in terms of protection and creation costs, defining and deploying security policies and building staff awareness and improving the overall security of the organization among others
Detection and analysis
This stage focuses on mitigation of asset impact caused by risk materialization. It is closely related to network monitoring described in the previous stage. The main source of information that helps an organization detecting those impacts are IDS, IPS, antivirus management consoles, firewalls, proxies’ logs… These should be properly managed in a SIEM by a SOC team.
Once the incident has been detected, either by analysing or correlating event logs, one must assess its impact and the nature of the attack to give it a level of priority and send a notification to all affected stakeholders. These might include other organizations, the original warner that could be outside or within the company, legal and communications departments, etc.
This stage is critical since it aims at preventing any further damage to other assets. It is key that the attacker does not notice CSIRT’s detection. If this were to happen the attacker might pursue further action such as deleting sensitive information or escalating his or her privileges. The organization should assess the viability of isolating affected systems by comparing the costs and benefits of keeping the systems operating, considering that said action could result in further damage to the systems, as would be the case of a severe Service Level Agreement’s (SLA) penalties. The organization should also determine the access point and root cause used by the attacker, in order to deploy safeguards that avoid the further exploitation of said vulnerabilities.
This stage’s goal is the recovery of all systems and their operations as well as the removal of the components or vulnerabilities that led to the incident. The deployment of all necessary improvements is essential to correct the root cause and increase the overall security of the organization.
Depending on the nature of the incident, the CSIRT will decide whether to restore the system, leaving unmodified the most possible systems or to rebuild a wider set of systems. It will be then when the incident response team will need to decide what backups will be restored in terms of backup completion date.
Through the different stages the CSIRT will have to document the entire process, including incident description, actions taken, author of those actions and justification. All information gathered from the event needs to be chronologically stored, checked for completion, reviewed and signed by senior management or legal counsel. In this stage, we must report to all affected stakeholders. Lastly, we must assess all damage, including staffing, legal, reputational, informational and technological. It will be at this stage when the response plan must be evaluated and reviewed for further improvement.
We sincerely hope that you don’t ever require stages three and four; but if you ever do, you will be prepared.
Do you see any opportunity for improvement? Share your experiences with us.