Many compliance regulations such as PCI-DSS and HIPAA require that data be completely hidden or partially masked for all users who are not authorized to see the data. When IBM i (AS/400, iSeries) customers implement DB2 Field Procedure (FieldProc) encryption, how do they implement data masking at the same time? In this blog I want to talk about general principles of data masking, how IBM DB2 FieldProc applications can implement data masking, and some limitations that you need to know.

Data Masking and the FieldProc Architecture
There is no direct facility provided by IBM in the DB2 FieldProc architecture to implement data masking for you. This means that your FieldProc application must implement this for you. FieldProc applications are written by you or provided by your vendor (see below for information about the Townsend Security solution). Since data masking is designed to protect sensitive data in the clear, this means that data masking should be implemented in the decryption logic. When a row is read from a database table the FieldProc application is called by DB2 to perform decryption. At that point the determination must be made on whether the user is allowed to see the entire column value in the clear, whether it should be partially masked, or whether it should be fully masked. 

Data Masking Security Architecture 

One of the core security principles of data masking is that it should be based on user whitelists and not on user object authority. This is not an intuitive idea for most IBM i system administrators because so much of IBM i security is based on file object level authorities. So why would data masking not rely on object authority?

One of the main efforts of a cyber criminal upon gaining access to your system to escalate their privilege level in order to access sensitive data and achieve the ability to manipulate system configurations. On the IBM i platform the attacker will try to gain security administrator privilege or All Object (*ALLOBJ) authority. If your data masking strategy is based on object authority it is immediately defeated when the attacker gains greater privilege. This is why data masking should be based on a whitelist approach and not on native object authorities, and why we took this approach in our Alliance AES/400 FieldProc implementation. 

Users and Groups
Like many other operating systems the IBM i provides for user groups. On the IBM i platform user groups are defined by a Group Profile, and individual users can belong to this group or it can be included in their supplemental group. Group profiles are a convenient way for IBM i security administrators to define authority rights for anyone in the group and not have to define these rights for each individual user. If you are a user you inherit the rights to the groups you belong to. A data masking implementation should incorporate user groups into its implementation through a whitelist approach.

Data Masking Options
Data masking options should allow for masking of an entire field, or just a portion of the field. The PCI Data Security Standard (PCI DSS) is probably most clear on data masking requirements for compliance. Only authorized users (defined by PCI as “personnel with a legitimate business need can see the full PAN”) should see an entire field unmasked and all others should see only a portion of the field (The first six and/or last four digits) or the field should be fully masked. When establishing your whitelist of users you should be able to define the data masking options at the same time as you define the user or the group.

Data Masking for Numeric Fields
On the IBM i platform we have a challenge when it comes to masking numeric fields. Numeric fields can only contain a numeric digit and can’t contain an asterisk or other typical masking character. For numeric fields you must determine a masking pattern that can’t naturally occur in the data. Perhaps you could choose a masking option that filled a numeric field with all 9’s. This would work if the field could not naturally contain all 9’s. An example might be a salary field. If you have a 9.2 zoned numeric field it is unlikely that anyone would have a salary equal to $9,999,999.99 and masking with all 9’s would work. Just be aware that masking numeric fields requires some forethought and planning.

Limitations and Gotchas
Data masking with FieldProc encryption is generally very effective and easy to do. But there are a few limitations. Consider a program that reads data from table A and uses a column value to read a record from table B. And assume that the value read from table A is encrypted. If a user can only see masked data, the data will be masked when read from table A and the lookup on table B will fail. This is a subtle limitation but it has occurred in the real world!

Summary
Data masking is a powerful additional security control for your FieldProc applications. If you are aware of the limitations it is a great tool to help you get better security for your IBM i databases and applications.

IBM i FieldProc encryption by Townsend Security
Townsend Security provides a full IBM DB2 FieldProc solution for the IBM i server platform with Alliance AES/400. In addition to strong 256-bit AES encryption, it provides IBM i customers with flexible data masking options on decryption. It has full support for individual and group profiles, and the security administrator can specify a default masking rule to apply to any users not explicitly allowed to see unmasked or partially masked data.