| Today, I wanted to discuss one new technology that we will be releasing as a part of Veeam Backup & Replication 9.5 Update 3. This is one of the new unplanned features that we did not even think about just a few months ago, but rather came up with in response to the newly observed realities and threats.
If you follow this digest closely, you remember that over half a year ago, I predicted the raise of insider attacks that will use Ransomware as a Service as the tool to make money along with satisfying their desire for revenge. What I could not possibly predict is the volume of those attacks, and also the fact that 9 out of 10 are performed by "insiders" which are hackers that have penetrated the network perimeter and obtained access to almighty credentials. We don't even know of all the customers who were affected, and rather only those who did open a support case for assistance with recovery from the attack – but even their number is 10x more than I ever expected would be.
I did share nitty gritty details on a few attacks with you before, but the scenario is always the same – an insider, be it a company's employee or [usually] a hacker gets inside of the environment remotely, obtains almighty credentials, installs ransomware on the production servers and deletes all backups from all backup software they find from the convenience of its user interface. Most of them are actually well aware what to look for on the network – many admit in their exchange with the victim that they specifically look for servers running Veeam and other well-known backup software, and they use quite sophisticated network analysis tools to find those on the network. They also rarely stop at the main data center alone, looking for any saved public cloud credentials to destroy the entire Amazon or Azure environments along with all their snapshots and replicas.
Pretty much every impacted customer had to pay the ransom, and they all asked us the same question – how Veeam can help us to prevent from happening in future? Of course, we would explain the usual story about the importance of air-gapped backups as the ultimate protection - and different means of achieving those (rotated drives for small environments, tape or storage with write protection embedded in hardware for larger shops). This really works and I am not shy recommending rotated drives approach for all small customers, because that's what we did ourselves in early days: our co-founder (wearing CIO, CTO and many other hats at the time) would just take the external hard drive with backups of a few most important VMs "offsite" to his apartment each Friday, slapping another one in place for next week's backups.
However, many customers were demanding automation of off-site backups, because they wanted to completely remove the human factor and not have to deal with physical security issues of the manual off-siting process. Especially so after one U.S. bank made the news by managing to lose a whole bag of tapes on the way to the vault. This was what pushed us to add Veeam Cloud Connect functionality, along with source side encryption and built-in WAN acceleration - and this functionality had tremendous success. But as we learnt recently, the one essential feature that Veeam Cloud Connect did not provide is some sort of air-gap, thus still leaving an insider the opportunity to just fire up the Veeam console and delete all those off-site backups sitting in the service provider environment! And this is exactly what we're addressing in the upcoming update.
Starting Update 3, your Veeam Cloud Connect service provider will have an option to enable new "insider protection" functionality on your tenant account. The concept is pretty simple – all deleted backup files are first moved to the "recycle bin" folder for the set amount of days – while from tenant perspective, they appear actually deleted and not consuming the storage quota. This functionality protects you from both straightforward deletion of all backups from the Veeam console, as well more sophisticated attack via reducing the job's retention policy and running a few incremental backups on already encrypted production servers to push the production data out of the off-site backup chain (protection against the latter does require enabling periodic or GFS full backups though). Note that I was careful not to use the term "air-gap" both here or in the UI for this functionality, because technically speaking, backup files remain "online" in the recycle bin and in theory, the attack can still be orchestrated through an additional insider in the service provider environment – but you'd probably agree the chance to coordinate something like this is extremely thin.
Now, you may be wondering what would be the recovery steps when from a tenant perspective when backups are completely gone from the Veeam console – just as you would have expected after deleting them? Simple - you just call your service provider, and ask your backups to be moved from the recycle bin back to your cloud repository folder. This process is actually very similar to how backup seeding is performed, so most service providers are already well versed with one. And this is the beauty of using a local Veeam service provider, as opposed to a hyper-scale public cloud – you can actually call the former, talk to a human and get help! Moreover, often you can even drive to their data center to have your backups copied off to a NAS box, and bring them back to your data center using 100TB/hr bandwidth provided by the fastest WAN transport out there that is a truck with hard drives. More importantly, with this new capability, Veeam service providers will be "protecting your data from yourself" so to speak – because unlike with "do it yourself" cloud backup approaches, you can't possibly access the back-end environment where your backup files reside, as is the case with any repositories that you set up and manage yourself. |
Komentáře
Okomentovat