Prepare for incidents and learn to recover

Inform the RIA Incident Handling Department CERT-EE (cert@cert.ee) about the occurrence of a cybersecurity incident. For additional consultation and incident analysis, the organisation must be prepared to share details of the incident and have a designated contact person authorised to communicate with CERT-EE.

In the event of an incident, start by documenting the situation:

1. save local and log server logs;
2. preserve configuration (e.g. firewall rules);
3. create disk images of affected systems;
4. save at least the last backup before the incident, and if possible, all backups of systems involved in the incident up to that point.

Once the situation is identified, define the scope of the incident, which includes mapping all affected systems. Compromised or potentially compromised systems should be isolated immediately.

During the recovery of IT services, it is important to avoid losing relevant evidence (logs) during the system restoration process. As a result of the root cause analysis of the incident, actions should be planned to prevent similar situations in the future.

In the event of a cyber incident, it is crucial to inform your clients or partners who are affected by the incident. In certain cases, such as a personal data breach, companies are obligated to notify the Data Protection Inspectorate. Additionally, during the resolution of the incident, consider whether a report should be submitted to the police.

It is important to have a recovery plan to ensure business continuity. While it may seem that you know how to restore a system in the event of a failure, Murphy’s Law suggests that you will need to recover it during the company’s busiest working hours, when the most knowledgeable specialist in that particular system is not available. In this case, a recovery plan can help you to restore the system quickly and correctly in the most critical situation.

The recovery plan must set out in detail all the information necessary for restoring the systems that are important for the company:

1. the people responsible for restoring the system, as well as their contact details;
2. description of hardware and software – all devices, tools, data, and software versions required for restoration with their exact location;
3. step-by-step process guide – what to do and in what order;
4. settings of the system to be restored;
5. users required for restoration (service accounts, administrator password, etc.).

In the event of a cyber incident, documents stored on the server may not be accessible, which
is why it is a good idea to keep a printed copy of the recovery plan in a pre-agreed location.

In addition to protecting IT systems, an organisation must have a good understanding of what is happening within them. This helps to detect potential attacks more quickly and understand how an attacker gained access.

To achieve this, logging must be properly configured and the recorded log data must be monitored. It is important that all necessary information is included in the logs – for example, network traffic, security devices, domain controllers, servers (including administrative actions), workstations, and applications. Logs should be retained for at least 1 year, preferably up to 3 years. This is necessary to determine, in the event of a security incident, when the suspicious activity began and which systems were affected – because an attacker may be present in the systems long before anything noticeable happens.

Logs should be stored on a separate server and backed up, so they are preserved even if the main system is compromised. It is also advisable to implement a monitoring solution that tracks system performance and security incidents, and sends automated alerts if needed, to enable a quick response to problems.

When planning a backup, the first step is to determine what data is important to the business and needs to be backed up. Everything you need – emails, business software databases, shared directories, and files – should be backed up and the data on users’ computers should be also taken into account. Among other things, it is also necessary to back up the data required for system recovery, such as the configuration files of servers or network devices and other technical information.

Second, it is also important to determine how far back the backup data should go. Important data, such as shared folders used on a daily basis or business software, may need to be backed up daily and retained for a month, for example (meaning that it is possible to restore data that is a month old). Data that does not change frequently (such as an image bank or archive) can be backed up once a month, with only a single copy kept.

An external backup should also be made to protect the backup copy in the event of an accident (fire, flood) or theft. That backup can be stored in the cloud, in another office, or, for example, hosted by a service provider. In addition, it is worth keeping one backup on a storage medium that is isolated from the network. When using a cloud service or external provider, keep in mind that your data will be hosted by a third party. Carefully consider whether it is appropriate to store backups of confidential data or trade secrets in such environments.

It is also important to ensure that backups are successful, as data cannot be recovered from a failed or corrupt copy. To do this, set up email notifications to confirm that backups are running, and regularly review the backup logs to ensure that the backups are completing successfully. It is a good idea to check periodically that all the necessary data is still backed up (for example, a folder may have been moved to another location and not configured for backup) and, if necessary, change the backup settings. In addition, it is important to keep documentation on backups: what kind of data is backed up, where it is backed up to, how many backups are kept, and which software is used for the process.

Regular recovery testing is very important. It involves restoring an important part of the system to a separate location from the current system (so that the working environment is not affected) and checking that everything is working after the restoration. Recovery testing is important because even if it seems that the backup copies have been successfully made, there may be errors during system restoration that cannot be foreseen. For example, a backup may be invalid, data may be missing, or additional settings may be required to restore the system. Any anomalies or special settings detected should be documented in the recovery plan. Recovery testing must be performed for all important systems and the backup for testing should be selected randomly.