Highlight these 4 areas in your malware incident response plan
The malware threat is on the rise, and recovery is no simple process. When planning a malware response, it's vital to get down specifics and eliminate unknown factors.
If the first half of 2018 is any indication, the rest of the year will see an increase in malware attacks. Malware can include viruses, worms, spyware and Trojan horses, all of which can cause an organization serious harm. Whether the attack intends to steal, encrypt or delete important data, having a malware incident response plan in place is vital to recovery.
According to the midyear update of SonicWall's Cyber Threat Report, malware attack frequency is on the rise:
Malware volume is up 102%.
Ransomware attacks are up 229%.
Encrypted attacks are up 275%.
Cryptojacking -- a relatively new attack vector -- has been used in 5.6 million Coinhive attacks in the first half of this year.
The challenge with crafting an exhaustive malware incident response plan is that the attack specifics are often unexpected. For example, if you were trying to prepare for a ransomware attack, you might look to industry data for an average number of affected systems. According to security awareness training vendor KnowBe4, the average number of systems affected in an attack is 16 workstations and five servers. In a recent attack on the National Bank of Blacksburg, however, 500 workstations and 120 of the bank's 150 servers were affected.
Regardless of the number of systems, applications and data attacked, you don't know ahead of time what will be affected. This unknown factor needs to be a part of your malware incident response plan. If you're going to be ready for this kind of disaster, there are a number of areas of your environment to be aware of that could end up requiring recovery.
Regardless of the number of systems, applications and data attacked, you don't know ahead of time what will be affected.
Endpoints. Attackers seeking to steal data will compromise endpoints to ensure they retain control to facilitate lateral movement and potential exfiltration of data. Endpoints are also the first targets of ransomware and cryptojacking. Because you may not want to have a malware recovery plan for every individual endpoint, you should identify key endpoints -- e.g., the CEO's laptop -- that need to be recovered quickly after an attack. For everyone else, having a process to reimage the machines is appropriate. I'm not a big fan of leaving a previously compromised machine in production just because it's supposedly been cleaned. To ensure there are no remnants of malware, they need to be wiped.
Servers. You should already have a disaster recovery (DR) plan in place for your servers. Part of your incident response to a malware attack is to kick those plans into gear, should you identify one or more servers being part of an attack. Like endpoints, affected servers need to be wiped and reimaged. Attackers seek to establish persistence on a given machine, so just because you think you deleted the malware files, doesn't mean the machine is clean. Reimage it.
Data. I'm not willing to put my trust in a hacker that encrypted my data, combed through my servers or stole data. That same person could intentionally or accidentally delete or manipulate data along the way. And I certainly am not going to trust their decryption mechanisms to properly put my data back into a known-good state. As part of your malware incident response plan, you need a way to identify what data has been accessed by compromised accounts and have a plan to recover it to a point in time that you know hasn't been touched by an attacker.
Directory services. Attackers determined to identify and steal valuable data are doubly interested in establishing persistence. In addition to the endpoint, attackers seek to obtain credentials that can give them the ability to create user accounts as another means of maintaining their ability to log on to the network. If they have several footholds in the network as a means of gaining entry and a few dozen accounts they've created and granted some level of elevated permissions, they can come and go as they please. And it's not just accounts you need to worry about -- there are ways of ensuring persistence through group membership, permission assignments and group policy settings.
There are two parts to consider in your malware incident response plan when it comes to directory services:
Some kind of change auditing that will let you know what changes were made and when (read: "How far back do I need to recover?")
The ability to either restore the directory back to before the changes were made and deal with the aftermath of any nonthreatening changes you've now wiped out with a restore, or to roll back individual actions
Ensuring proper malware recovery
DR plans are usually specific and scenario-based; for example, "should server x die, we recover to the cloud and execute failover." But with malware attacks, the scenario is rather high-level with only potential victims in mind.
As the likelihood of a malware attack increases, you'll need to formulate a malware incident response plan that addresses how to get the system back to a place where it is in a known state and have the ability to do the same for any given workstation, server, data set or directory setting that may be impacted by an attack. It's not impossible, but it will require you to separate critical and noncritical workloads and deal with each independently -- all under the assumption that any one of them could be affected by an attack.
Dig Deeper on Disaster recovery planning and management
