Next, delve into the logistics of incident response. If a ransom scenario occurs, who needs to be brought in? What items can you check safely, if any?
You might be able to stave off any direct, hacker-caused damage by cutting all remote access (assuming the attacker isn't an insider). Is that a risk you're willing to take, especially given what happened to Code Spaces? Also, how long can your company's online presence go down without dire business repercussions?
Is an Internet kill switch possible, where you completely disable all remote access immediately in a single step? Could you implement procedures to accomplish it? It's harder to accomplish today, particularly if your environment is a mixture of on-premise and cloud-based resources.
The key is to discuss the ransom scenario, ask questions, get answers, and document procedures and tasks. The worst time to have these hard discussions is during your first ransom event.
Ensure survival through backups
The No. 1 preventive measure you can take is to maintain good, protected backups of all mission-critical assets and data. In the Code Spaces case, the company said its "offsite" backups were destroyed, making recovery impossible. Those backups may have been offsite -- but they were also online.
It's vital to store recent copies of your backups both offsite and offline. I'm amazed how many companies think that resources without an IP address -- but contactable using a virtual machine manager or KVM switch -- are considered "offline." They are not! If you can reach a resource over the network, it's not offline. If you can reach a resource over a network, so can the attacker.
Backups shouldn't be the only assets kept offline. I routinely work at companies that have their "offline" root CA (certification authority) servers turned off, located on a networked virtual server host. Again, this is not offline. I have been involved in two instances where attackers copied the "offline" root CA image to their remote offices, cracked the admin passwords, and issued themselves trusted digital certificates. In one of those instances, they issued themselves smart cards and work badges, then physically entered the site.
Just as important is how many companies don't really have backups -- or tested backups that can be restored. Almost every security audit I run contains the finding that backups are insufficient and/or untested. When I am involved with test restores, most of the time, they fail.
It's also critical to understand how your data is backed up in the cloud. Is it backed up, and if so, how? Is it possible for a cyber criminal to access your backups and delete them? How would you get the cloud vendor to initiate a restore? Have they tested a restore? If a cyber criminal deleted your current data, would those deletes be immediately replicated to the backups? Are server configurations backed up or merely the data?
Sign up for MIS Asia eNewsletters.