Code Spaces thought it was prepared for a disaster.
The code hosting provider had backups. It used the cloud. It had successfully operated for seven years.
But one day, in the space of about 12 hours, the company was completely and permanently dismantled. And within 10 days, Code Spaces ceased to exist.
It wasn’t a hurricane or tsunami, an infrastructure failure or power outage that shut the company down. The reason Code Spaces shut its doors forever was a ransom attack that compromised its credentials.
All it Takes Is One Cyberattack
You may remember the story. Before cyberattacks went mainstream and became one of the most popular and pernicious threats, this case of compromised credentials became a shining example of what not to do when it comes to business continuity.
And for good reason. Code Spaces is not alone by any means. Some 60 percent of small businesses will close permanently within six months of a cyberattack.
By examining the many things that went wrong that day, you can turn a more discerning eye on your own resiliency to make sure your business stays up and running whether you’re hit by a cyberattack, a natural disaster or any other unexpected event.
Here’s what Code Spaces could have done before, during and after the incident to minimize the damage. Learn from its example.
Never Hand Out Full Admin Credentials
The first mistake Code Spaces made was having full administrator access credentials for its cloud control panel.
A hacker got hold of those credentials and gained access. When the company attempted to regain control by changing passwords, the attacker, who had made multiple backup logins, started deleting files at random. The company’s data, backups, off-site backups, machine configurations and more were nearly wiped out when the dust settled.
The principle of least privileged access applies here. Offering full admin access can provide convenience in the near term, but invites disaster should any bad actors gain control of those credentials.
Give employees the access they need to complete their jobs, and no more. Split up responsibilities to limit the reach any one user has.
Take steps to secure those credentials using two-factor authentication and by regularly coaching employees to recognize phishing attempts, among other methods. But if those credentials are compromised, least privileged access will contain any damage.
Keep Your Backups Separate and Secure
Code Spaces’ old website claimed it offered a “real-time backup solution that allows us to keep off-site, fully functional backups of your data.”
Yet those off-site backups were apparently tied into the same control panel as the backups and original data. That was a mistake. Just as you shouldn’t back up your on-premises servers to a building across the street, if a disaster hits the primary system, it’s likely to hit the backups too.
Keeping backups separate is especially crucial in defending against cyberattacks. If your system is locked down but you can fail over to the backup, you can remain immune to the threat.
If, however, your backups are linked to your primary data, an attack could lock down or corrupt your backups as well. Know where your backups are stored and whether they’re safe.
Plan for the Worst-Case Scenario
The “well-practiced” recovery plan that Code Spaces advertised was no match for the hacker. The potential for an attacker to steal credentials and create backup logins for its control panel went overlooked.
If Code Spaces had planned out what to do in the case of a breach, it might not have been caught so flatfooted. At the very least, Code Spaces could have had an extra copy of its data, and could have returned to business as usual for its customers as it cleaned up the hacker’s mess.
But backups alone aren’t enough. Different disasters have different impacts, and your backups won’t help if you don’t have the infrastructure or procedures for recovering it.
Assign responsibility to specific team members for the recovery process, or seek out managed recovery services to handle process and governance as well as the recovery. Plan for the worst-case scenarios, from hackers to hurricanes to power outages to equipment failures.
Test Your Plan at Least Twice a Year
Test more frequently for your most important applications and data. While Code Spaces said it tested its recovery plan, it might not have been putting its systems through the most rigorous tests.
Many organizations stage a test to show that their plan works rather than actively trying to push the limits of their systems, process and team.
A plan alone leaves you no safer than a company without a plan. Don’t see if your plan works during an actual disaster. Test frequently to take into account system changes, application updates, new infrastructure and other changes that could upend any plan you think you have in place.
It takes time and effort, but when disaster strikes, you’ll be practiced and prepared to recover quickly.
Don’t Be the Next Code Spaces
The day after the attack, Code Spaces’ homepage was simply a letter to customers explaining what had happened and that the cost of the attack and refunds — combined with the hit to its reputation — would put it out of business for good.
It spent the following days and weeks recovering what customer data it could, and then turned out the lights.
It’s the kind of attack that could happen to any business.
Take the time to review your security posture and disaster recovery plans. The time, effort and resources spent in ensuring your business resiliency are a pittance compared with the consequences of losing your business entirely. Plan accordingly.