Security Aspects

Security is very important to me, and transparency is a must to assess the quality of a product. Key aspects of security are authentication, authorization, and encryption. And encryption applied to data stored on disks or communicated across some network.

Authentication

In order to do a backup or restore you must authenticate with the Lindenberg Software Backup server, i.e. you need a valid user and password for the backup server. The user does not need to be a member of the Users group, i.e. does not need to be allowed to logon to the server interactively, a network login is sufficient. You can use users defined locally, Microsoft accounts, or Active Directory domain users. For domain users you can authenticate with any login variant plus using the email address stored for the user in the directory. The Backup client stores the credentials used to authenticate in the registry. The credentials are encrypted using the Windows Data Protection API - see Microsoft's information on security aspects of credentials stored with CRYPTPROTECT_LOCAL_MACHINE. Starting with version 1.4.8186.39319 you can select not to store credentials when starting without Bitlocker. (Anyone using Veracrypt? please let me know.) This feature was added to better support recovery scenarios using Windows-To-Go.

On the server Lindenberg Software Backup relies on the Windows operating system to manage users and credentials.

Users used for authentication should be different for different administrators/owners of computers. If owners/administrators overlap partially for different computers, you may want to use a different user per computer. This minimizes the risk of an administrator accessing files she is not supposed to access.

Authorization

In order to use Lindenberg Software Backup, the user must have read authorization on the directory you configure to use for backup, and must have read and write authorization to the backup files accessed. Lindenberg Software Backup helps you to do that by automatically creating a directory for every user as he starts using backup, and assigns read and write authorizations on that directory for the specific user, and of course also to the system and administrators group. Other users do not have read or write authorizations on the directories unless you specifically grant that. The backup server impersonates the authenticated user where possible. In other words the exact same authorizations are in effect as if the user were accessing the backup files locally on the server (assuming the user can log in) or via other network services like file sharing (if configured).

Lindenberg Software Backup exposes the backup images as a network share read only for the "Mount" feature to work. Backup does not expose the backup images for write access in order to prevent the backup images being modified by ransomware. The share is automatically configure to only show directories and files the user is authorized to see.

When using the "Start VM" feature, Lindenberg Software Backup automatically assigns connect authorization to the requesting user, which of course must have authorization to the backup as a prerequisite. Backup does not grant Hyper-V Administrator or Remote Management roles to the user, nor does connecting to a virtual machine require any of these (although VMConnect, Microsofts standard tool, merges management features with remote desktop connection, and thus requires too many authorizations).

Summary: users can never access any backup they are not authorized to access, nor see any directory they are not authorized to access.

Auditing

Lindenberg Software Backup server tracks backup activities including mounting a backup or virtual machines in an event log at navigation path Application and Services Logs / Lindenberg_Software / Backup / Server / Admin, that can be viewed with event viewer. Note that this feature requires .NET framework 4.6.2 or newer.

Encryption of communication

Lindenberg Software Backup supports https to protect your data and credentials during communication. In order to ensure data and credentials are sent to the correct server you need to use proper server certificates. For encryption Lindenberg Software Backup relies on Windows and .NET, but allows only Transport Layer Security (TLS) versions 1.0, 1.1, and 1.2. Note that if both systems support 1.2, 1.2 will be negotiated, and 1.0 and 1.1 are only there to ensure backward compatibility with old systems. Also note the Windows TLS implementation does not share the same vulnerabilities known for other implementations (see Solving the TLS 1.0 problem.)

Remote Desktop Protocol (RDP) connections to virtual machines use a self-signed certificate by default. You can follow Microsofts documentation Configuring Certificates for Virtual Machine Connection to replace that certificate, but when you use FreeRDP via Lindenberg Software Backup, Lindenberg Software Backup takes care to pass along the hash of the certificate used as a trust anchor. Unfortunately, that is not yet possible with Guacamole (see Guacamole Integration) as Guacamole is not yet using a recent version of FreeRDP, but as long as Guacamole is running on the same physical host as Lindenberg Software Backup that is acceptable. If you run Guacamole and Lindenberg Software Backup on different hosts, then please replace the certificate with a trusted one.

Lindenberg Software Backup exposes the backup images as a network share read only for the "Mount" feature to work. The share is configured to require encryption and thus requires Server Message Block 3.0.

While both Remote Desktop Protocol - used for connecting to virtual machines with the "Start VM" feature - and Server Message Block, the protocol used for windows file sharing and used with the "Mount" feature, support encryption, and as documented above, the share exposed by Backup enforces encryption, use is recommended only within local area network or using virtual private network connections. You should never open any of the involved ports in your router connecting you to the internet. If you want to allow access to share or virtual machines via the internet, Lindenberg Software Backup can automatically establish a virtual private network connection.

Encryption of disks

Lindenberg Software Backup does not support client-side encryption, sometimes also called end-to-end encryption, nor does it encrypt the data stored on disks on its own.

I definitely recommend to use full disk encryption for both the client and the server, e.g. Bitlocker or Veracrypt. All my Windows systems (except virtual machines where the host is encrypted) are encrypted using Bitlocker. You have to be aware that when doing a backup, the data is decrypted. In fact I experimented with doing backups of the encrypted partitions, however due to the stacking of drivers and Volume Shadow Service in Windows, it is impossible to do a consistent but encrypted backup of a mounted volume (and usually you want to work with your data, don´t you). With that said, it is obvious that you have to encrypt the data in communications (see above) and that you should encrypt the target volume as well. Btw., an advantage of the fact that Lindenberg Software Backup processes unencrypted data is that it can compress data during communication, which usually does not work with encrypted data, that there is the option to deduplicate data on the backend storage (untested so far), and that Lindenberg Software Backup can start a virtual system out of the backup.

Warning: you must deposit your encryption keys in a safe place and you need to do regular backups of any encrypted data.

In case a backup user does not want the administrator of the backup server to be able to access some of the files, you can use the following mechanisms to implement client-side encryption:

Encrypting File System (EFS) to encrypt files in selected directories (e.g. the user´s profile path, C:\Users\<user>) . Without knowledge of the user´s password - be sure to use good passwords - or encryption certificates, or of the recovery agent certficate with private key, nobody can access file contents protected by EFS. A nice property of EFS with Lindenberg Software Backup is that if you mount a backup on the original system and accessing the encrypted files as an authorized user, this is entirely transparent. Note that metadata like file names is not encrypted by Encrypting File System (EFS).
encrypted containers like
- virtual hard disks stored on your disk that you encrypt using Bitlocker. A task scheduled to run at login can be used to mount and unlock the disk.
- VeraCrypt virtual encrypted disk (also called file-hosted volumes) can be used and Veracrypts Backgroundtask supports the auto-mount feature in order to ease access for the legitimate user.
Note that in both cases you can use a password or a key that is protected with EFS.

You may wonder why Lindenberg Software Backup does not provide end-to-end-encryption, do you? There are two important reasons to it:

With end-to-end-encryption, virtualization is not possible and thus the most interesting capabilities of Lindenberg Software Backup are just not possible.
Encryption is damn difficult to get right. For the curious please check out Schneier´s law and the interesting discussions around about solutions. Thus I prefer to recommend proven solutions over implementing encryption on my own.