Data at rest encryption considerations — NetBackup 10.3 | Cohesity Documentation

Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist

Data at rest encryption considerations — NetBackup 10.3 | Cohesity Documentation

NetBackup™ Security and Encryption Guide

Data at rest encryption considerations

The following table describes the data at rest encryption limitations.

Table: Data at rest encryption limitations

Limitation	Description
Computer performance effect of data encryption	Encryption algorithms are like data compressions algorithms in that they are very CPU intensive. Compressing data without the addition of computer hardware (either dedicated or shared), can affect computer and NetBackup performance.
Data compression must be performed before data encryption	Data compression algorithms look for data patterns to compress the data. Encryption algorithms scramble the data and remove any patterns. Therefore if data compression is desired, it must be done before the data encryption step.
Choice of an encryption algorithm	There are many encryption algorithms and associated key sizes. What should a user choose for data encryption? AES (Advanced Encryption Standard) is the standard for data encryption and supports 128, 192, or 256 -bit encryption keys.
Suggested key size	Generally, the larger key the more secure, and the longer into the future the data will stay secure. AES is one of the best choices because it is deemed secure with all three supported (128, 192, 256 bit) key sizes.
FIPS certification for my encryption solution	While FIPS certification may be required for use by the US government, it should not be the only criteria that is used to evaluate an encryption solution. Other considerations should be part of any decision-making process as follows: FIPS certificates only apply to the named version of a product. And then only when the product is used in conformance with the "FIPS security policy" the document that is submitted when the product was validated. Future product versions and non-standard uses would be subject to questioned validation. The security of algorithms like AES is not in the obscurity of how they work. Rather the security is in the difficulty to deduce an unknown encryption key. The years of scrutiny and peer review for AES, have lead to mature implementations. In fact, tests exist for AES where specific keys and data sets are input, and verified against the expected output. Data encryption is much like automobile security. Most problems are related to lost or misplaced keys and not related to malfunctioning locks. Since misuse is more likely to lead to problems, the usability of an encryption product should be part of the consideration. Usability considerations include the following: Encryption integration with the product Encryption integration with business processes. Appropriate encryption key granularity Recoverability
Appropriate encryption key granularity	The appropriate encryption key granularity is best explained with the example of home security. A single house key is convenient. You can enter the garage, front door, or backdoor all using the same key. This security is good until the key is compromised (for example, if the key is stolen). Then you need to change all the locks that used the key. An extreme example is to have a key for every drawer and cupboard in a house. Then, a lost key would require the changing of on a single lock. The correct solution is somewhere in between. You must understand your tolerance for a compromised or lost key from your business process perspective. A lost key implies all the data that is encrypted with that key is destroyed. A compromised key implies all the data that is encrypted with that key must be decrypted and reencrypted to become secure.

Feedback

Was this page helpful?

Feedback

Was this page helpful?