Your security incident is now contained, and the attacker no longer has access to the assets they compromised.
But how do we get back to normal?
This is the aim of the resolution phase: to take all the necessary steps to return to normal.
As a result, you need to make sure that:
the damage has been repaired.
the attacker can no longer return.
the incident will never happen again.
Plan for Getting Everything Back to Normal
Repair the Damage Caused
The type of damage caused by the incident can fall into one of three categories:
Data leaks
Unavailable services. For example, an incident can shut down an industrial production site, resulting in considerable delays and loss of earnings for the organization.
Asset destruction: document encryption, backup destruction, data deletion, etc.
However, the role of the SOC is definitely to communicate, fix, and monitor the security conditions for getting the system back to normal.
Damage Caused by Data Leaks
When there are data leaks, the risks are more of a legal nature. It’s not your role to take these steps, but you should make sure they are carried out.
Deal With Compromised Assets
Dealing with impacted assets involves restoring compromised or damaged assets to their full working condition and the required security level.
This process will immobilize the assets for a variable period of time, preventing the Méditronique teams from using them as they normally would. In addition, it results in changes to the affected systems, which we try to avoid as much as possible unless the changes are anticipated, planned, and communicated to the relevant teams.
So, there’s a decision to be made between:
thoroughly treating the asset or keeping it available.
minimizing the changes or taking advantage of them to improve IS security.
Rebuild the System
Rebuilding a system is the most reliable way to ensure that it has been restored to the right security level. But in practice, the affected systems are sometimes very complex or tailored to the organization’s environment.
For this reason, we prefer to rebuild from scratch when the security upgrade requires a complete overhaul of the system. The potential risk in this scenario tips the benefit–risk balance toward a full rebuild.
Clean the System
Conversely, cleaning the system requires an in-depth analysis of what the attacker has done, looking for backdoor access and signs of damage. You then have to repair any damage that has been inflicted and disable the backdoor access.
This process can take a long time, depending on the incident! But the advantage is that the system continues to operate while it’s being treated.
Cleaning is the preferred option when the system is too critical to be stopped or altered, such as an industrial system, the directory, or a critical network service.
It’s also possible that the data may be critical or overly complicated to recover for the purpose of rebuilding the system. For example, when it’s possible, we’d rather rebuild a customer database than start from scratch.
We also prefer to clean the system when we have the time, because the potential complications of the incident are resolved by other means. Isolate the network, secure its configuration, or install an EDR or EPP.
Resolve the Cause of the Incident
Beyond the systems, is the IS itself being repaired? How can we ensure that this incident never happens again?
To prevent a recurrence, we need to identify the root cause of the incident. It may be a vulnerability, bad practice, or an attack that could not be identified or blocked in time.
As you made your way through the treatment process, the investigation should have helped you to identify the initial cause of the incident.
It’s your responsibility to organize the measures to be taken.
If it’s a vulnerability, install any patches that may be available. If not, you should plan to create a patch and disable any vulnerable components until the patch is ready.
If it’s bad practice, there needs to be a serious discussion about it. The incident provides a good opportunity to build awareness among the relevant people and explain the risks that were successfully avoided—or the damage that was inflicted!It’s not about blaming people. It’s about educating them. The aim is to make sure they understand what needs to be done to avoid this incident and to support your efforts.
If the attack was not the organization’s fault, how could you have detected and blocked it? Or perhaps it was detected but not handled in time? In short, continuously improving your SOC is imperative.
Over to You!
A critical server has been compromised in Méditronique’s backup infrastructure, and you have to handle the situation. As a reminder, this is the compromise path that has been identified:
The attacker retrieved the eve.lefevre@meditronique.com account credentials from a public data breach.
They logged into the VPN with this account.
They exploited a vulnerability on an obsolete server and stole the backup server’s local admin password.
You need to deal with the compromised assets.
Complete the following table to decide between rebuilding the assets or cleaning them, considering that:
an investigation has already been carried out on the backup server.
this server is critical to the backup infrastructure.
Criteria/asset | The eve.lefevre@meditronique.com account and local admin account | Backup server | Obsolete server |
Ease of rebuild | Medium |
| Simple |
Ease of cleaning |
|
(investigation already complete) | Complex |
Security status before the incident | N/A | Good |
|
Impact of unavailability | Low |
| Medium |
Decision |
|
|
|
Find the answers to the table accompanied by an explanation in this downloadable document.
Let’s Recap!
Once the situation has stabilized, it’s time to move on to the incident resolution phase. This involves handling the initial cause of the incident and repairing the damage caused by the attack.
To treat a system, you have to decide whether to rebuild it or clean it, depending on the circumstances. Generally, the two principles are to a) minimize the impact on the information system and b) resolve the incident with the most secure configuration possible.
That’s why we prefer to rebuild from scratch when the initial system did not have adequate security and the work required to rebuild it is less than the work required to secure it. This option also ensures that the attacker has not left any way of regaining access.
Cleaning is preferred when the system is too critical to be stopped or altered and can be secured by other methods, such as by isolating the network, securing its configuration, or installing an EDR or EPP.
We also need to get to the root of the problem that caused the incident in the first place. If necessary, correct the vulnerability that allowed the attacker to gain access to the IS.
Once everything is back to normal, has the incident been resolved?
No, there are still things that need to be done before we can close the incident for good. We’ll go into more detail in the following chapter!
