To encrypt or not to encrypt, that is the question.
Well, you should of course be encrypting data in motion particularly where it’s to be carried over a third party network such as the internet or the networks operated by data warehouses where cloud service providers (CSPs) locate their equipment.
Given remote working and the move of IT into the cloud, where your services will be operated in a multi-tenanted environment, you should be seriously looking at encrypting data flowing between systems as well as between users and systems.
One example is to encrypt the data flow between an email app such as Outlook and the email server such as Microsoft Exchange. This is easily done via set-up menus and should be done even if the main communications channel itself is encrypted.
Encrypting between systems is recommended though you will need to review individual applications to see what is available, here however Microsoft servers can encrypt end to end using the Server Message Block (SMB) encryption feature.
Websites both internally and externally facing should be using HTTPS by default and service and maintenance access to systems should also be encrypted (SSH, HTTPS, proprietary) remember though that data must be in the clear (decrypted) before it can be processed, we are a few years away from applications being able to process encrypted data directly in an economic way.
Meanwhile, data at rest should also be encrypted, and most database systems offer encryption selectable between fields or records. Some file systems (both hardware and software based) can offer encryption, examples being Microsoft BitLocker on Windows 10 and later (and Server 2008 and later) although for Windows 11 there is a requirement for TPM 2.0 (Trusted Platform Module) support.
For Microsoft Server 2016 TPM is not a requirement but is recommended, however if Host Guardian services are required then TPM 2.0 is a definite requirement.
Other encrypting file systems include APFS on macOS 10.3 and later; Ext4 on Linux kernel 4.1 and Novel Storage Services. See Wikipedia for more examples.
Encryption of data at rest is not a panacea or silver bullet as far as protecting data is concerned. It won’t for instance protect you if a ransomware gang accesses your data store, it will quite happily encrypt your encrypted data! As such a well-designed and engineered infrastructure with careful attention to security configurations throughout is a must! Put least privilege into action, and CISOs, if your managers or board complain, get them to sign a formal affidavit that they understand the risks of not limiting file access according to an absolute business need and that they are therefore fully liable should things go wrong.
What are the best encryption standards?
We’ve talked about the need for encryption and where, but what standards should we be aspiring to? My recommendations are:
- AES 192-bit encryption algorithm, although for high security systems 256 bit could be looked at (there is a cost vs. risk discussion here).
- Where public key cryptographic systems are too used to protect the AES key exchange processes (a shared symmetric key), we should be looking at 2048-bit RSA although 4096 bit-RSA is available and useable with a small additional impact on performance. Whether that small performance hit will be noticeable given currently available CPU power is debatable and using 4096-bit RSA will afford some additional comfort. Again, it’s a risk vs cost analysis.
Remember that data at rest includes not just the data on file and database servers, it includes email systems and peoples PCs, laptops, smartphones and USB devices. And data in motion doesn’t only travel between systems or systems and user devices but also sent to printers and backup systems. Don’t forget them whatever you do. They could be the back door you forgot!