Eugene Wypior
Ransomware in OT – Response Strategy
Last week we described how to best prepare for a potential ransomware attack in the OT environment from the perspective of the three main areas – people, processes, and technology.
Today, we look at best practices of identifying, limiting, removing, restoring operations, and looking at the aftermath in the event a ransomware incident does happen despite all efforts to prevent it.
First steps – Identifying
Once a ransomware attack has been positively identified it is helpful to establish which ransomware strain is behind it (LockBit, Conti, Black Bast, etc) in order to streamline the containment and recovery actions.
Parallel to this the scope of the incident needs to be established – identifying the locations, devices and systems affected.
Yet parallel to the previous two actions, the collection of relevant evidence must begin to be collected right away for later forensic analysis.
It is helpful to be familiar with the characteristic tactics and techniques deployed by the various adversaries to better counteract the attack as well as the many common attack vectors widely used such as Microsoft Power Shell, VPNs, RDs, or vendor tools.
Secondary first steps – Limiting
As important as identifying the source and scope of the attack is the immediate action aiming at the limitation of the spread of the infection to more locations and devices.
For that, the infected systems should be disconnected from the network.
Based on the Incident Response Plan (IRP) identify whether critical assets have been affected and whether core operations can carry on.
Second steps – removing the threat and restoring operations
This step depends heavily on the first step of collecting information on the cause of the incident and the way the adversary has infiltrated the environment where all ‘doors’ through which access was gained and potential exfiltration happened had been closed and any malicious code has been dealt with to prevent secondary and tertiary infections.
It is a good idea to stay informed about available decryption tools for popular ransomware and adversary groups, but at the same time keep in mind that even if a decryption tool is offered by the adversary, the process of restoring data may be time-consuming.
As result, many organisations afflicted by ransomware decide to restore from a backup just because it is faster, and may be more reliant, than using the appropriate decryption tool. This consideration of decrypting versus restoring from a backup will be normally covered by the IRP in place and it is important to have exercised restoring operations from a backup beforehand.
If the operations have been restored from a backup the system might need to be checked against the findings from the initial stages of the incident in case the backup itself already contained signs of a breach and for any vulnerabilities to be closed.
Any outstanding patches and/or updates of firmware, etc will have to be applied as well at this point to decrease the risk of a future repeated or new attack.
After the incident
A review of the attack is conducted and areas, where security can be improved to prevent future attacks, are identified and the Incident Response Procedures are improved.
Backup and restore procedures including any gold images, configuration files, and logical and physical network configurations are updated.
Notifying the stakeholders
Depending on factors such as:
- The severity and scope of the attack
- Type of data lost/exfiltrated
- Jurisdiction
the incident will have to be reported to various stakeholders such as
- Law enforcement agencies
- any other relevant stakeholders (customers, shareholders, etc)
Ransom
It is important to note that paying the ransom is not recommended as it only encourages further attacks and does not guarantee the restoration of the encrypted files however it is reported that often companies do pay the ransom quietly as not to endanger the operations and to tarnish their reputation.
0 Comments