IBM has done a good job of implementing security from the ground up on the IBM i platform. But that doesn’t mean that it is immune from data breaches. All of the PCs and servers on your network with the IBM i server are potential attack points for a data breach. And make no mistake, cyber criminals know that the IBM i server is a rich target. Implementing encryption in IBM i DB2 is an essential part of a defense in depth strategy. But there are lots of pitfalls to avoid. Let’s take a look at some of them (I am shamelessly plugging our Alliance AES/400 solution, too):

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 that you store encryption keys away from the IBM i server in an encryption key vault designed for this purpose. Why is this a security best practice? Cybercriminals are often able to achieve privilege escalation on a compromised IBM i server and then get access to locally stored keys. Storing encryption keys off of the IBM i server makes the compromise of the sensitive data much harder.

How Townsend Security Can Help

The Townsend Security Alliance AES/400 product integrates seamlessly with Townsend Security's Alliance Key Manager solution for protection of encryption keys and key management best practices. Alliance Key Manager stores encryption keys in a hardware security module or VMware instance that is attached to the IBM i server by a secure, authenticated TLS connection. As a FIPS 140-2 compliant key management solution, Alliance AES/400 with Alliance Key Manager solves the key management problem!

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 solution 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, the 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 Townsend Security Can Help

Alliance Key Manager implements real-time key mirroring to one or more backup key servers. The mirroring implementation is active-active meaning that any changes you make to keys or access policies on the secondary server will be mirrored to the production server when it comes back online. This perfectly matches your IBM i high availability failover strategy if you use MIMIX, iTera, Vision, or IBM DataMirror.

Encryption and Insider Threats

Insider threats include both intentional and unintentional access to and loss of sensitive information. Unintentional losses of data represents the largest insider threat. 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 Townsend Security Can Help

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 security audit journal QAUDJRN. You can achieve effective Separation of Duties between managers of the encryption keys and security administrators on the IBM i platform.

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 the new IBM i POWER8 servers with on-chip encryption, 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 in order to avoid negative impacts to both interactive and batch applications.

How Townsend Security Can Help

Alliance AES/400 uses the Townsend Security NIST-validated AES encryption library for encryption and decryption tasks. This optimized AES encryption library is more than 100x faster that native IBM i encryption libraries on POWER7 processors, and more than 50x faster on POWER8 processors.

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. Most IBM i customers 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 native the SQL Query Engine.

How Townsend Security Can Help

Townsend Security tackled the problem of encrypted indexes and offers a solution to the RPG challenge through its Open Access for RPG SQL library. 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.

Data Masking

Compliance regulations such as PCI Data Security Standard (PCI-DSS) and security best practices require that we only allow authorized users access to fully decrypted sensitive data. But other users must have access to our 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 Townsend Security 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.

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, and 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 Townsend Security Can Help

Alliance AES/400 and Alliance Key Manager implement system logging and audit 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, and transmits 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. The optional Alliance LogAgent solution transmits these logs as well as all IBM i security events to a SIEM solution or log collection server.

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

Patrick