Dangers of Encryption on the IBM i (AS/400, i series): 7 Pitfalls to Avoid

IBM’s security implementation on the IBM i platform is good, but that doesn’t mean that it’s immune from data breaches. All PCs and servers on the same network as your IBM i server are potential attack points for a data breach. There’s no doubt that cyber criminals know that the IBM i server is a rich target.

Implementing encryption in IBM i Db2 is an essential part of an in-depth defense strategy. But there are lots of pitfalls to avoid. Let’s take a look at seven common dangers (including how Precisely’s Assure Encryption can help in each area):

1. Poorly performing encryption libraries

Encryption can also present an operational risk to IBM i customers. In order to meet service level expectations of end users, encryption and decryption operations must be efficient. Unfortunately for IBM i customers, the native AES encryption software libraries provided in the operating system may not provide an adequate level of performance. Even with on-chip encryption, delivered beginning with POWER8 servers, the performance of AES encryption and decryption tasks is poor. It is important to assess the size of your protected databases and the nature of batch operations that require access to unencrypted data to avoid negative impacts to both interactive and batch applications.

How Assure Encryption can help

Assure Encryption uses an AES encryption library for encryption and decryption tasks. This optimized AES encryption library is more than 100x faster than native IBM i encryption libraries on POWER7 processors, and more than 50x faster on POWER8 processors.

2. Encrypted indexes

Many IBM i customers are surprised to learn that their RPG applications will not work correctly with Db2 FieldProc for encrypted indexes (key fields). FieldProc is IBM’s automatic column level encryption feature implemented at the Db2 database level.

FieldProc is attractive to IBM i customers because it does not require modifications to applications. While native SQL applications can easily handle encrypted indexes, RPG applications do not use the native SQL Query Engine (SQE) and will not work properly with encrypted indexes. If you are among the majority of IBM i customers that exclusively use RPG or have a mix of RPG and SQL applications, the issue with RPG and encrypted indexes represents a major roadblock to encryption.

Be sure that your encryption strategy can support encrypted indexes or be prepared to modernize RPG applications to use the native SQL Query Engine.

How Assure Encryption can help

The problem of encrypted indexes is tackled by Assure Encryption’s Open Access for RPG SQL module. Changing one line of code in your RPG application can automatically use the native SQL Query Engine for database access. This eliminates the challenges of encrypted indexes with FieldProc encryption.

3. Encryption and insider threats

Insider threats include both intentional and unintentional access to, and loss of, sensitive information.

Unintentional loss of data is the largest insider threat to your data security. Accidentally copying data to a PC or development environment can lead to a reportable data breach event. This is especially true when access controls to sensitive data are only controlled by native IBM i object level security. You should certainly use native IBM i security mechanisms, but access to decrypted sensitive data should also be controlled using a “whitelist” approach. This will help minimize the intentional and unintentional access by security administrators.

Note that it is not only the security profile QSECOFR that has all access to sensitive data. All users with All Object (*ALLOBJ) authority or who adopt this level of authority through a group profile or supplemental group are at risk for intentional or unintentional loss of sensitive data.

How Assure Encryption can help

Assure Encryption implements a whitelist approach for controlled access to decrypted sensitive data. All configuration changes to security policies are logged to the IBM i security audit journal (QAUDJRN). Whitelisting can allow you to achieve effective Separation of Duties between managers of encryption keys and security administrators on the IBM i platform.

4. Data masking

Compliance regulations such as PCI Data Security Standard (PCI-DSS) and security best practices require that only authorized users be allowed access to fully decrypted sensitive data. But other users must have access to database applications. This means that intelligent data masking should be built into your IBM i applications. As noted above, data masking should be based on a whitelist approach and not purely based on object or database level authority. You should have the ability to define masking rules (mask all but the last 4 characters, etc.) and you should be able to define a default masking rule that applies to all unauthorized users. While Row and Column Access Controls (RCAC) can provide some data masking capability, you must manage individual user level authorities to implement this control.

How Assure Encryption can help

Assure Encryption fully implements data masking using a whitelist approach and provides protections from users with All Object (*ALLOBJ) or Security Administrator (*SECADM) privileges. Data is masked in the internal decryption routines and fully exposed data is never visible in the application program.

5. Locally stored encryption keys and key management

One of the surest ways to defeat your encryption strategy is to store encryption keys on the same system that stores sensitive data. The IBM i server is no exception.

Compliance regulations and security best practices require encryption keys be stored away from the IBM i server in an encryption key vault designed for this purpose. What makes this a security best practice? Cyber criminals are often able to achieve privilege escalation on a compromised IBM i server, giving them access to locally stored keys. Storing encryption keys off of the IBM i server makes the compromise of the sensitive data significantly more difficult.

How Assure Encryption and Townsend Security’s Alliance Key Manager can help

Precisely’s Assure Encryption integrates seamlessly with the Alliance Key Manager by Townsend Security for protection of encryption keys and key management best practices. Alliance Key Manager can store encryption keys in VMware, the cloud (AWS, Azure, IBM Cloud) or a traditional hardware security module (HSM) in your data center or as a Cloud HSM. As a FIPS 140-2 compliant key management solution, Assure Encryption with Alliance Key Manager solves the key management problem!

6. High availability and key mirroring

Encryption key management is a part of your critical infrastructure. The loss of an encryption key means the loss of your data!
Your encryption key management software should implement real-time key mirroring and real-time security policy mirroring. In the event the key manager is unavailable due to a hardware or network failure, failover to a secondary key server should be automatic without business interruption. A key management solution based on the IBM i master key facility cannot achieve real-time mirroring and protection from these failures.

How Assure Encryption and Townsend Security’s Alliance Key Manager can help

Townsend Security’s Alliance Key Manager implements real-time key mirroring to one or more backup key servers. The mirroring implementation is bidirectional, meaning that changes made to keys or access policies on the secondary server are mirrored to the production server when it comes back online. High Availability products from Precisely are a match for this key failover strategy.

7. System audit logs

No security policy or solution can be effective on a stand-alone basis, and this includes encryption and key management. A good encryption and key management strategy involves:

• monitoring all access to sensitive data
• monitoring changes to encryption and key management configurations
• monitoring all use of encryption keys
• storing audit logs for future forensic reference.

The use of Security Information and Event Management (SIEM) solutions is highly recommended as a part of your monitoring and alerting strategy. Be sure that all access to encryption and encryption keys is fully audited and logged.

How Assure Encryption and LogAgent can help

Assure Encryption and Townsend’s Alliance Key Manager implement system logging to enable auditing for all aspects of administration, configuration and use. Alliance Key Manager implements full logging of all aspects of key management and the server it runs on, transmitting logs to a SIEM solution in real time. Assure Encryption fully logs all administrative operations and decryption tasks to the IBM i security audit journal (QAUDJRN).

Conclusion

Encryption and key management don’t need to feel dangerous or scary! Hopefully the above points about encryption and key management for the IBM i help you develop a roadmap for safe and successful encryption.

But encryption is just one component of a full best practice security solution for your IBM i system. Check out Assure Security for comprehensive coverage.

For information on Precisely’s NIST-certified encryption software, read our eBook: IBM i Encryption with FieldProc and Assure Encryption: Protecting Data at Rest