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, authorisation, 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. On the server Lindenberg Software Backup relies on the Windows operating system to manage users and credentials.

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. If you want to receive an A grade from SSL Labs then you need to disable the RC4 cipher as described at http://windowsitpro.com/windows/disabling-rc4-cipher or https://samrueby.com/2015/06/08/how-to-disable-sslv3-and-rc4-ciphers-in-iis/.

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 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. Without knowledge of the user´s password, nobody can access file contents protected by EFS. 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.