3 Things to Add to Your Ransomware Incident Response Plan

By Chris Tuzeneu

3 Things to Add to Your Ransomware IRP

I had the opportunity recently to speak with an individual who worked with an Incident Response Team that specifically works with organizations who have been hit by a ransomware attack. In hearing about his procedures and methodologies, I was introduced to elements of ransomware aftermath that I had not previously considered. There are factors that are difficult to take into account when you have not lived through such an event, but learning from the experiences of others can at least help enhance our existing Incident Response Plans, even if we are fortunate enough to never fall victim to such an attack.

Negotiating the ransom. You may have heard of contract negotiation vendors, who use their experiences with various cores and Managed Service Providers to get you the best deal on your upcoming contract renewal. In a similar fashion, there exist cybersecurity companies who will reach out to the perpetrators of the ransomware attack and try to negotiate a cheaper Bitcoin price to unlock your files. In many cases, the authors or distributors of the ransomware are organized much like a business, and will respond to support requests or make concessions on their ransom price if they are asked. In a worst-case scenario, this can help to mitigate financial losses as well as reduce the amount of the claim filed with the cyber insurance company.

Time and trouble with decryption. In every case of recovering from a ransomware attack, no organization is back up and running immediately. When the ransom demands are met, usually the attackers will provide a decryption program, which may or may not work successfully in recovering entire systems. In some cases, the program will work correctly on one computer but not on another. Usually the program will allow for mass decryption of files, but it may sometimes lack that functionality and will only decrypt files one at a time. Then middleware must be constructed to iterate through files and pass the command to the decryptor, if it even supports that function. Sometimes they just don't work at all, and the attackers’ support hotline must be contacted for troubleshooting. Most of the time they will be obliging, because a lot of their revenue could potentially be lost if they gain the reputation of not delivering what is promised when they are paid. It is a strange sort of underground economy.

Post-payload backups. The first thing on anyone's mind when they are confronted with ransomware is their backup solution. If a ransomware attack is successful, that means there is some weakness in the scope or efficacy of the backup solution being used. This can be problematic even during the file decryption process, as many decryption programs will delete the encrypted file as it is being processed and decrypted. This is no issue if the software works as intended, but if there is any kind of error with file decryption the original file is lost. Therefore, it is actually a good practice to perform a manual backup of the encrypted files post-attack, to avoid complete loss of data if the ransomware decryption program fails to perform as advertised.

This is all worst-case scenario thinking. But, isn’t that at the core of a good, effective Incident Response Plan? Adding these considerations to your plan will not only make it more robust in the eyes of regulators but will also help to increase the odds of successful recovery if this ever happens to your organization.