Dangers of Encryption on the IBM i (AS/400, iSeries): 7 Pitfalls to Avoid
Syncsort recently acquired the IBM i encryption and security products of Townsend Security. The article below is an update to their popular blog post on the dangers of encryption on the IBM i.
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 Syncsort’s Alliance AES/400 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 Alliance AES/400 Can Help
Syncsort’s Alliance AES/400 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 Alliance AES/400 Can Help
The problem of encrypted indexes is tackled by Alliance AES/400’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 Alliance AES/400 Can Help
Syncsort’s Alliance AES/400 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 Alliance AES/400 Can Help
Alliance AES/400 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 Alliance AES/400 and Townsend Security’s Alliance Key Manager Can Help
Syncsort’s Alliance AES/400 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, Alliance AES/400 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 Alliance AES/400 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 Syncsort 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 Alliance AES/400 and Alliance LogAgent Suite Can Help
Syncsort’s Alliance AES/400 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. Alliance AES/400 fully logs all administrative operations and decryption tasks to the IBM i security audit journal (QAUDJRN). Syncsort’s Alliance LogAgent Suite can be added to the solution to transmit these logs as well as all IBM i security events to a SIEM solution or log collection server.
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.
For more information about IBM i data security and encryption, watch our webcast Top 5 Encryption Myths for IBM i Users