In a previous article we looked at the some of the principles regarding mitigation after a cyber-attack on a company. This time we will breakdown the requirements for carrying out regular backups as well as the process of recovery of the backup as part of a Disaster Recovery plan when that process is put into action.
Backup Regularity
The need to have your operational data backed up has been an ongoing process from the time before the “great” cloud emergence. In those days we held multiple tapes with all the data for a day, week, month, or year in multiple locations. Usually in a fireproof and floodproof safe, with copies being either held onsite or at an offsite location. This as we know is okay for the short term. In the long term the tapes could eventually degrade, limiting our actions to recover data from them.
With the more flexible approach of using SANs (Storage Area Network), NAS (Network Attached Storage) and cloud based backup storage the process of backing up production data has become more second nature to many companies today. Here at Tycom our main backup process is split between having an onsite NAS device at most client sites, which acts as the onsite backup, and a cloud copy of the same data, usually backed up at the end of the working day, to reduce any impact to the operations of the companies involved. There are, however, some companies that Tycom works alongside where they have foregone the onsite SAN or NAS and backup their production data directly to the cloud. In many cases this is good for the environment, eliminating the power cost of having additional devices onsite.
The regularity of the backup ensures that all data flowing through the business is captured and as up to date as possible, and as close to the time or date of any recovery requirement, if it is ever required…
The Disaster Recovery Process
As stated in some earlier articles having a well-defined Disaster Recovery process can be a lifeline to any company who needs to activate the policy, to regain their business footing after a cyber-attack, regardless of the severity of the incident. A key part of the breathing life back into your company’s productivity is ensuring all the daily business data is accessible. This is made easier with already having a well-defined backup process as part of everyday activities within the company infrastructure.
The Data Recovery Process
If ever required, the backup process can be carried out any number of ways. The data recovery work could be delegated to the appointed company MSP in the most part, leaving clients to get on with their everyday roles.
When the DR process is instigated, different teams can be set into action to carry out their delegated tasks to start bringing together the various areas of recovery into a homogeneous functional mass. Within these processes will be constant dialogue throughout the company, discussing everything from what security to implement to mitigate future issues, right down to at what point of the backed up data should the recovery team start from, i.e., from the previous day’s backup or even from another day’s backup. This would ultimately depend on verification as to when a breach occurred, what was breached, the length of the incursion, whether or not the threat actor(s) have been penetrating the network for an extended period of time, leaving multiple backdoors into the system for future access. This would add additional tasks onto the recovery team as to how far into the stored backups should they go to verify that any breach tools haven’t been bundled up inside the scheduled backup data.
Taking the understanding that ‘logically’ the backed up data is completely intact and free from malicious code following is a number of recovery options that can be implemented:
Bare metal recovery – This is the process of recovering any data required (unaffected by any possible breach) directly onto a new/repurposed unformatted device. This can be expensive to consider, especially if you don’t have a spare physical server lying about in a storeroom, and if the said device hasn’t been used for a while and the system operating system hasn’t been updated for a while.
Recovery to a New/Existing Virtual Machine – This is one of the more modern facilities preferred for those who want a fast restore of their data. The recovered data could be downloaded from the cloud storage or directly from the onsite backup solution. The benefit of restoring directly on to a new VM is that it will be on readily available equipment, and maybe created directly on a device which had been breached. However, this would not take place until the device in question has been fully checked for any lingering issues which allowed a breach to take place.
The following recovery can act as an interim solution while the recovery to a new/existing virtual machine is completed:
Recovery to a cloud based virtual machine – For those already working directly with tools like Microsoft’s Azure and Amazon’s AWS (and other related products) this seems to be the way to the future for some companies. For those with onsite infrastructure but with their backups directly in the cloud a simple addition of a copy of their servers could be started within the cloud and all their onsite infrastructure pointed to that virtual machine as the default server, until their onsite devices have been prepared and secured ready for the data to be restored to it.
As stated above some larger companies, out-with the Tycom client pool, have taken the leap to have all their actual network infrastructure within the cloud environment. This could be seen as the future for business networking, with only items like switches, firewalls and computers/laptops/tablets being the onsite physical presence of the company’s network infrastructure. This would see the heavy power items, the company servers, being hosted in the cloud and any costs would be levied from the “compute” power consumed by use of these devices and cost for storage and retrieval of the company’s data. However, full cloud integration and cloud computing is a story for another article.