Why should organizations—including IBM i shops—consider using encryption to protect their data? Carol describes the areas where encryption can be used and why she’s a strong believer in implementing it.

Large financial institutions used to be the only organizations that implemented encryption. Now it’s becoming more commonplace. Why? One reason is because it’s become easier to implement; you no longer need hardware encryption cards, for example. But another reason is because more organizations realize that encryption is a vital layer of defense for protecting their data—often the last layer to prevent compromise. And I fully agree with that reason. As you know, I’m a huge fan of multiple layers of defense, and encryption is one of those important layers. Let’s take a look at the various ways encryption can be implemented on IBM i.

Data in Motion

One of the ways organizations can protect their data is to encrypt data “in motion.” This means that all transmission of data is encrypted. Many organizations have been doing this for the transfer of data outside of their organization. What I want to encourage is that all transmission of data is encrypted, including data transferred within your own network. Sometimes I get pushback when I suggest organizations encrypt internal communications. They argue that it’s their own network, so why should it be encrypted? My counter is to point them to any one of the security-related newsletters that are available and show them the plethora of articles that describe how a hacker or rogue insider plants a sniffer on the network and gathers user ids and passwords to gain access to servers around the network. So all communications—not just those to and from IBM i—need to be encrypted to eliminate this exposure.

IBM has made configuring encrypted sessions on IBM i relatively easy. You can choose to create the digital certificates required on IBM i itself or request them from an internal or well-known CA and import them. Access Client Solutions (ACS) has made configuring the client-side of the transmission much easier than it was with the old Client Access client. There’s very little excuse for not encrypting internal communications and eliminating this exposure.

If you aren’t encrypting transmissions leaving your organization, you need to take a serious look at these connections. Why would you ever want to send credentials (user ids and passwords) through the Internet in cleartext, not to mention your data! Yikes! Many of these connections are to banks or trading partners and carry critical or sensitive data. If these connections are not already encrypted, run do not walk to your workstation and connect with your contact on the other end of the connection and start the work necessary to encrypt all of your external communications. The only valid reason for not encrypting external communications is if the organization being communicated refuses or cannot accommodate an encrypted session. Today, however, there should be very few of these situations remaining.

Data at Rest

When the credit-card industry started to require all cardholder data be encrypted, IBM i shops had the painful task of restructuring any file that contained encrypted data. That’s because encrypting a field in a database file usually resulted in the field becoming longer and sometimes a different type. This caused applications to have to recompile any program using the file, in addition to adding the calls to encrypt and subsequently decrypt the fields upon access. But as of V7R1, IBM i has the feature called Field Procedure. FIELDPROC, as it’s referred to, has significantly reduced the challenge of encrypting data at rest, eliminating the need for applications to recompile programs using files with encrypted data as well as eliminating the need to add calls to encryption/decryption routines. The operating system stores the encrypted data in the internal structure of the database. As a result, the length and type of the field remains the same. Also, an encryption routine is automatically called when the field is either written to or read. Because of this reduction in complexity and the elimination of the need to significantly rework applications, more organizations are choosing to encrypt data at rest. In the scheme of implementing multiple layers of defense, encrypting the data at the field level is your last layer before data becomes available. In other words, even if users have authority to the file, by using FIELDPROC you can control who will see the fully decrypted information. The reason this is so important is because most application database files contain what I call “mixed” data—that is, some fields contain general, non-confidential information, and others contain PII data. This stems from the fact that no one imagined 20 years ago that social security or social insurance numbers would be considered private information. Today, we’d never design databases that contain this type of mixed data, but since most organizations don’t have the luxury of redesigning their applications, we’re stuck working with this database design. Because of the mixed data, more users need authority to the file than should have access to the PII data contained in the file; therefore, your best line of defense for protecting the confidential or PII data is to use FIELDPROC and encrypt it, and then specify which users can see the fully decrypted data, semi-masked data, or fully masked data.

With FIELDPROC, IBM has provided the enablement of encryption, but the operating system doesn’t actually do the encryption. While you could write your own encryption/decryption routines, I don’t recommend it. These routines are only part of the encryption picture. The parts of implementing encryption that need special attention aren’t the encryption/decryption routines; it’s the key management aspect. Key management includes encryption key generation, storage, and management, including the ability to have multiple inputs to generate the master key or randomly generate it, encrypting the data encryption keys, providing the ability to change keys when they reach their end of life or someone leaves, and more. Key management is key (pun intended) to a successful data encryption scheme. Vendor products have solved this problem and provide solutions that include the encryption routines, key management, and methods for determining which users see the full data or masked data.

What doesn’t protect your data? Disk encryption. I’ve heard some organizations assert that they are already encrypting their data on IBM i using full disk encryption and therefore don’t need to implement FIELDPROC. That absolutely isn’t the case. The only scenario where disk encryption protects your data is when you swap out a disk. Otherwise, data is automatically decrypted whenever it’s accessed when full disk encryption has been implemented. Full disk encryption offers no options for specifying who can see fully decrypted data; data is always decrypted on access. Please do not fool yourself (or your management) into believing full disk encryption is a viable layer of defense against inappropriate access of your organization’s data.

Like object-level security, FIELDPROC provides protection regardless of how the information is accessed—via an application menu, FTP, ODBC, remote command, command line, etc. This is why I feel there’s a strong case for using FIELDPROC as a layer of defense to protect your data. In addition, if data is stolen and the person inappropriately accessing the data doesn’t have authority to the fully decrypted data, you may eliminate some of the breach-reporting requirements that are in effect in countries around the world.

Encrypted Backup

If you haven’t considered encrypted backups, you should. This technology isn’t for all organizations, but should the media containing your backup be lost or stolen and if that backup contains PII, most of the breach-notification laws around the world either exempt the organization from reporting or, in the case of GDPR, while loss of data will have to be reported, you won’t have to notify the individuals and fines are reduced or eliminated. Talk to any organization that has had to notify individuals that their data was lost and had to provide credit-monitoring services because backup media wasn’t encrypted; they’ll tell you they wish they had invested in encrypted backups. Now this, like encrypting data at rest, takes planning. Once again, key management is key. But also, you must think through your disaster recovery plans to make sure that the hardware or software used to encrypt the media is available at your alternate data center or hot site should you have to go into disaster recovery mode.

Summary

Yes, encryption takes planning. Yes, it’s easier to not encrypt sessions, data, and backups. But in many instances, it is the final line of defense to protect your data from inappropriate access and significant business disruption that follows the loss or theft of data. I encourage you to discuss this important feature with management. Help them understand the options available so they can determine whether this is a layer of defense they want implemented to help reduce risk to your data and systems.