INTRODUCTION
Information, now mostly in the form of digital data, is a critical asset for all companies, from the smallest to the largest.
The ISO/IEC 27001 standard reminds us what the requirements and best practices are for best managing the security of this information.
The three core principles are:
- Confidentiality: not everyone can access a particular piece of private information, only people with the right permissions
- Integrity of information: the data that the organization uses to conduct its business or that it keeps safe for others must be stored reliably, ensuring that it is not deleted or damaged
- Availability of data: data must be available at all times, so that anyone with authorization can access the information whenever necessary
VEEAM'S ROLE
To protect this data, software solutions like Veeam Backup & Replication are crucial because they help to achieve the three mentioned cardinal principles of information security.
Specifically, Veeam allows us to:
- create backups and replicas of our data, which means additional copies of the original information → help preserve integrity
- keep backups protected from malicious action, hardware problems or disastrous natural events , leveraging immutability, air gapped and offsite copy→ helps keep the data always available
- save our data through secure protocols and in an encrypted way→ helps maintain confidentiality
All this translates into Veeam's fundamental rule, the famous 3-2-1-1-0.
To this rule, indeed, I would add a property to be applied globally: encryption.
VEEAM ENCRYPTION - WHY AND HOW IT WORKS
Just like encryption on the original data, encryption of backups is not a practice that is always used, sometimes for reasons of "compatibility" with deduplication appliances, sometimes because we forget or do not consider it as necessary.
In my opinion, however, it is one of the keys to ensuring the confidentiality of information.
Whether we save backups on an external cloud or inside our datacenter, it is imperative to ensure that anyone with access to this data cannot read it unless authorized.
Data exfiltration is something that can impact our backups as well, and if they are not encrypted any instance of VBR can read them.
Veeam provides both encryption in transit, that is, during the copy of the original data to the designated repository, and encryption at rest, that is, applied to the backup itself.
Traffic encryption is based on TLS (since the latest version of Veeam v12.1, TLS 1.3 is also supported).
Backup file encryption, on the other hand, is based on the Veeam Cryptographic Module and Microsoft Crypto API libraries, which are both FIPS compliant.
To encrypt the data, a single-key encryption algorithm is used, which means a single key is used to encrypt and decrypt, leveraging the AES-256 standard.
Without going into too much detail about Cipher, KEX and so on, what I would like to describe is the hierarchical scheme and workflow of encryption in Veeam:
Starting from the bottom, we find:
- session key: used on backup data blocks, changes with each backup session
- metakey: used to encrypt backup metadata; like the session key, it changes with each backup session
- storage key: the previous two keys are themselves encrypted by the storage key, which is used at the restore point level; in fact, when a backup chain is transformed and some backup data blocks are rewritten within a full ( for example, during syntetic full, reverse incremental, forever forward incremental.. operations), a single restore point will contain multiple session keys. The single storage key is able to act on the single restore point. It is maintained in the config db until the retention of the associated restore point expires.
- user key: when the Veeam administrator creates an encryption password, and then enables encryption on a backup job, this password is used to generate the user key. This key, which acts at the job level itself, is used to encrypt the storage keys that will be generated for each individual restore point within the chain of this job
- backup server keys: optional key pair, generated when connecting a backup server to the VBEM; according to the RSA asymmetric algorithm, the public key is passed to the VBEM, while the private key is kept in the VBR db. The key pair will be used to securely identify the backup server during any decryption request to the Enterprise Manager, according to the "password loss protection" feature
- enterprise manager keys: optional key pair, generated when connecting a backup server to the VBEM; according to the RSA asymmetric algorithm, the public key is passed to the backup server, and it is used to encrypt the session keys in the same way as the user key; the private key is kept in the VBEM db and used in case of decryption, according to the "password loss protection" functionality
During a backup job so, along with the encrypted data blocks, the cryptograms of the session keys, metakey, storage key (one encrypted with the user key and one with the EM public key), user key, and EM public key are saved, which will then be used to identify the corresponding keys when performing a restore.
PASSWORD LOSS PROTECTION
As anticipated earlier, there is a feature in Veeam Enterprise Manager that allows a second chance to decrypt backups in case our backup server no longer has the password, for example, perhaps because they are old backups that had been removed from the configuration.
Prerequisites
- VUL or socket licenses of at least Enterprise type
- EM and original backup servers connected
As of Veeam 12.1, the password loss protection feature also supports integration with KMS.
The key pair created by the EM is called a keyset. New keysets can be created, exported or imported.
You can set the automatic generation of new keysets, and the retention period of them.
The passwordless restore process consists of the following steps:
1) the Veeam admin starts the "encryption key restore" process from the backup server
2) this wizard generates a request that contains, in an encrypted manner, the storage key and EM public key references used during backup to encrypt that data
3) the request is passed to the EM admin
4) EM admin starts the "password recovery" wizard in the EM and enters the received request
5) EM finds the corresponding keyset
6) EM, using the EM private key, decrypts the storage key and enters it into a response file
7) EM admin sends this response to the Veeam admin
8) the Veeam admin enters this response into the "encryption key restore" wizard, completing the decryption process
Limitations: if you lose the backup server, or the EM, or the EM keyset you will not be able to use the recovery procedure.
The only way to be truly safe when using encryption is to never lose the user password.
So, the basic rule is: SAVE THE ENCRYPTION PASSWORD SAFELY, perhaps applying the 3-2-1-1-0 golden rule even for this data!
FEATURE REQUEST
Activating encryption is a useful process, but also a potentially risky one if the right steps are not followed.
For structured companies, with internal figures of reference such as DPOs and/or CISOs, it might help to create a procedure related to the encryption activation on backup data, documenting the various activities required also for the purpose of certifications and/or compliance policies.
Thinking about how this scenario could be integrated into Veeam Backup & Replication, I can have a few possible features come to mind that could be introduced:
1) Create a new "Security Role” within the VBR, which can be associated specifically with reference figures such as DPO/CISO. This role, which must have at least two associated users, can be used for encryption password activation and modification
2)Password activation and modification must be subject to 4-eyes authentication, and may be approved by a Veeam Administrator or Security Role
3) If the procedures for activating/changing an encryption password have been approved by a "Security Role," I would add a green checkmark of the type "security approval" or "approved by security" (similar to the "password loss protection" check). This "certifies" that the procedure has followed the right internal process, and allows backup administrators to assess whether the encryption password has indeed been secured properly
4) integrate this check into the Security & Compliance Analyzer
5) integrate the events of these new features into the existing VBR logs and alerts/reports of Veeam ONE
CONCLUSION
In these times when cyber attacks are becoming more and more frequent, viewing backups as something secondary is a mistake not to be made; they should be viewed more as an indispensable extension of our data.
Using best practices is strongly recommended..3-2-1-1-0 rule with encryption!
REFERENCES
https://helpcenter.veeam.com/docs/backup/vsphere/data_encryption.html?ver=120
https://helpcenter.veeam.com/docs/backup/em/em_manage_keys.html?ver=120
