File Encryption
It’s important to encrypt individual sensitive files on all virtual or physical devices. Failure to do so can allow an attacker to copy information onto insecure media or send it through insecure communication channels, rendering the sensitive info insecure. Several popular tools are available to encrypt/decrypt specific files – PGP and Zip. PGP uses both symmetric and asymmetric crypto keys (we cover asymmetric crypto in blog 2 of our crypto series), and there is an open-source version available, OpenPGP. Zip uses AES as described above and is available for all major operating systems. You will find numerous implementations of zip available; take note of the strength of the encryption key used. The larger the key, the more secure, but larger key sizes create larger zip files. If storage space is at a premium in your system, this trade-off must be carefully considered.
Many applications also allow files to be signed with a key, reducing the risk of undiscovered tampering of sensitive information. You sign a file for the same reason you might sign a paper document with a pen – to let readers know that you created the document or that the document has your approval. Everyone who recognizes your signature can confirm that you wrote the letter. Similarly, when you sign a file digitally, anyone who “recognizes” your digital signature knows that the file came from you. The process of recognizing signatures is called verification. You can design your application only to use approved (signed) files for specific functions.
Database Encryption
Information in databases presents one of the most challenging data security issues. There are many approaches to securing databases, and a method that works best for one Database Management System (DBMS) might not work for all.
Sensitive information in databases must be encrypted, but the correct approach varies with the DBMS and the requirements of the applications processing that information. While encrypting databases solves some problems, it can create new ones.
| Encryption Type | How it Works | Risks |
| Hardware-Based | Database resides on raw partitions, separate from the boot, file, and operating systems. | Backup and restore need to happen for both the DB and the files on the non-DB partition. |
| Whole Disk | Databases residing as part of the formatted file system. | Can leave backups and exported data unsecured because only the media itself is secured, not the information in the database. |
| DBMS-based encryption | Multiple techniques, e.g., – Transparent data encryption (TDE) – Column-level encryption – Field-level encryption | Solves the problem of backup and export data being unsecured but often leaves data exposed to queries. If an attacker issues Structured Query Language (SQL) commands against the DB, the encrypted data in the DB is no longer secure. |
| Server-side application-based | Sensitive data is encrypted by the application querying the DB, and the DB has no knowledge that the info is encrypted. | Might expose information in memory or over the networks and can limit the ability to perform ad-hoc queries on encrypted data. |
| Client-side application-based | Sensitive data is encrypted by the client application, and neither the server nor the DB has any knowledge that the data is encrypted. | Can create key-management issues, especially in systems with numerous client access points. Also, any client-side processing is susceptible to attack, hijacking, and spoofing. |
Backups are often among the most significant holes in an organization’s information protection processes. They almost always contain unencrypted sensitive information unless it is encrypted at the file level. For example, backups of encrypted disks produce unencrypted archives when using whole disk encryption because the unencrypted files are being backed up, not the encrypted raw disk sectors. Similarly, backups of database transaction records and database archives themselves are unencrypted unless the records in the database itself are encrypted.
If you first encrypt your data before backup, the primary risks are related to key management. If keys are not managed in an “isolated system,” system administrators with malicious intent may have the ability to decrypt sensitive data using keys they have access to. The fundamental principle of keys also gives rise to a potentially devastating risk. If keys are lost, the encrypted data is essentially lost, considering decryption without keys is nearly impossible. Store your keys as carefully as you store your backup – and keep them segregated from the backed-up data the key(s) unlock.
Finally, “off-site” backups are often out of your physical control, rendering them vulnerable to unauthorized access. Theft of backups is a common means of obtaining a path into an organization – mainly for the reason stated above, i.e., most backed-up data is unencrypted. There is no substitute for encrypting every backup.
About Ed Adams, CEO
Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.
Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security, and is a BoSTEM Advisory Committee member.


