Backup Monitoring: Part 6—Securing Your Backup Devices
In prior posts, as well as during my monthly office hours and quarterly boot camp sessions, I have touched on a number of security topics as they relate to SolarWinds® Backup. This always seems to draw a lot of questions, so I felt it appropriate to expand on those topics a bit more in a dedicated blog post, and provide some additional guidance and resources for those who want more information.
Controlling Platform Access
One method of securing backups is to restrict access to the backup platform. Now depending on the platform used to deploy and monitor SolarWinds Backup, you’ll have different options, but they all share common ground. Your first step is to use the role-based security features of the platform to give access to only those who need it—this way the number of individuals who can add, remove, modify, or perform recovery from backup becomes a known, manageable quantity. Remember, not everyone needs to be granted administrator- or super user-level access to do their daily job, and nothing is wrong with having a second login to access critical functions.
If you haven’t done so already, fully enable the two-factor authentication (2FA) features of the platform. Please, don’t hold off another day on this as it is one of the biggest obstacles to an individual trying to gain unauthorized access to your platform. Now while you’re at it, let’s address the topic of password reuse. It is a bad idea; you already know this, so please just stop. Your passwords for your accounts should not be intermingled with passwords for your clients. You should not have used or currently be using their passwords to access their network or systems. Demand your own credentials wherever possible so that during a security audit you can distinguish exactly who did what and when.
Finally, invest in a password manager application you can use for your personal life and keep it separate from the application or instance that you use for managing passwords for your clients. Then, get your clients to do the same thing, because it only takes one leaked or compromised password for the bad guys to get access.
Controlling Client Access
You might think that having direct or remote access to the local server or workstation would allow someone to accidentally or maliciously damage the backup and the backup history, but it doesn’t have to be this way. SolarWinds has taken several steps to control or prevent unauthorized access at the local backup client. One of the first few things a virus or ransomware will try to do is remove or damage your ability to recover from the infection. They do this in numerous ways, either by deleting snapshots, corrupting or encrypting backup files, uninstalling applications, etc. before they go about damaging or encrypting your data and volumes.
Since SolarWinds Backup is a “cloud-first” backup solution, damage to data on the local system has little to no impact on the already completed backups that are stored securely in our regional datacenters. i.e. the “SolarWinds Cloud.” The act of uninstalling the backup software does not result in the removal of any of the historic cloud backups and even a force cleaning of backups under retention cannot be achieved without first supplying the individual device’s private encryption key or passphrase.
Short of uninstalling the backup software, which could easily be reinstalled, the worst that a bad actor might be able to do is adjust your backup selections, modify exclusion filters, remove a backup schedule, adjust a setting, or trigger a restore. All of this can easily be blocked by setting a local GUI password or locked down granularly through the use of backup profiles.
Data Security
Security isn’t just about access, however; it is also about how data is secured and where data is secured. So to expand on that topic let us start with the fact that all backup data, whether in motion or at rest, is first deduped, compressed, and then encrypted on the local client using an AES-256 bit encryption algorithm before being sent to local disk or over SSL port 443 through a TLS version 1.2 tunnel to the SolarWinds Cloud. The process is reversed during restore, with encrypted data being retrieved from the SolarWinds Cloud over an SSL connection and then being decrypted by a local device possessing a valid encryption key or passphrase.
At the time of publication, SolarWinds maintains 30+ data centers across 17 countries and four continents. Our data center facilities maintain numerous certifications, such as ISO 27001, ISO 9001, and other certifications depending on your chosen region. The specific certifications for each data center can be found in our Data Center Security document, which also includes information on choosing storage locations and physical security measures at the data centers.
Data Retention
Data retention is a component of security; it ensures that you have multiple restore points in place from which to recover lost or damaged data. All editions of SolarWinds Backup default to a standard, rolling 28-day calendar retention model than can be expanded, using optional archiving rules to retain monthly or quarterly recovery points. In addition, the N‑central integrated version of SolarWinds Backup also supports 60- and 90-day product retention options, while the standalone version of SolarWinds Backup offers custom, user-defined retention models.
Backup Frequency
Since you can only recover data that you have protected, another way to secure customer data is by reducing the time between backups. This can be achieved by shrinking the Recovery Point Objective (RPO) and running multiple backups throughout the day using our Backup Accelerator technology, which tracks file changes between backups. This combined with backup profiles that allow for high frequency backup scheduling allows multiple daily backups to occur with minimal impact to the production system.
Redundancy
Backup redundancy can be achieved using an optional LocalSpeedVault (LSV). The LSV acts as a local backup and restore cache of your protected data and can point to just about any local disk source. The LSV, when direct configured on a direct attached volume, can be at risk of volume-level encryption or deletion, just like any other volume, so we recommend using a central NAS that is not on the domain, that uses workgroup level security, and is not used for any other purpose, with no user shares or mapped drives. The only access to the LSV should be the account the Backup manager uses to access the data.
Special efforts have been taken to help ensure the backup client will not upload corrupted or damaged data from an LSV if the data managed to be corrupted or damaged before it could be synchronized up to the cloud. Additionally, if the LSV remains offline in a failure state for 14 days (default) with unsynchronized data, we will take action to disable the vault and self-heal the cloud copy from the local device as best as possible.
Unauthorized Access or Accidental Deletion
Contact support immediately if you suspect unauthorized access or changes have been made to your backup platform. This includes missing or deleted devices, whether accidental or malicious. The team should be able to assist you in reviewing those changes and/or attempting to undelete devices.
Eric Harless is the Head Backup Nerd at SolarWinds MSP. Eric has worked with SolarWinds Backup since 2013 and has over 25+ years of data protection industry experience in sales, support, marketing, systems engineering, and product management.
You can follow Eric on Twitter @backup_nerd
Other blogs in this series
Want to stay up to date?
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.