Db2 for z/OS column mask functionality: part of an effective data security strategy

Authors: Gayathiri (Gaya) Chandran and Robert Catterall

Introduction

A column mask is a database object that describes a specific column access control rule for a column. In the form of an SQL CASE expression, the rule specifies the condition under which a user, group, or role can receive the masked values that are returned for a column. Column masks can be created on all base tables except materialized query tables.

A recent post in this blog by Emil Kotrc, “Unmasking the masked data,” brought awareness to a potential risk with using column masks. In this article, we will review some important Db2 for z/OS security best practices and explain how you can take a multi-layered security approach to mitigate the exposure pointed out by Emil. 

Db2 for z/OS security best practices, 
and their relation to column mask security risk mitigation

• Tightly control the IDs that can access the Db2 catalog tables - specifically, the securityrelated
catalog tables. Column mask definitions are stored in the SYSIBM.SYSCONTROLS catalog table. Only Db2 security administrators (i.e., those with SECADM authority) have the authority to define column masks. Restricting who can view information in catalog tables reduces the exposure that can come with knowledge of the specifics of Db2 security definitions.

• Use secure authentication mechanisms such as multi-factor authentication (MFA), AT-TLS client certificate authentication, RACF PassTickets to connect to Db2. A person attempting to gain unauthorized access to data values could try to accomplish that via a network connection to a Db2 system. Configure Db2 trusted contexts to enforce security attributes of connections to the Db2 system, and to limit the scope of user access to data for specific connections.

• Sharply limit the number of IDs that can do what is necessary to accomplish unauthorized access via table-joins. One thing that is required for the access-via-join process (described in Emil’s article) to work is the authority to access data in the table containing the masked column (call that T1). That being the case, an organization would be advised to 1) limit the number of IDs to which SELECT ON T1 has been granted, and 2) limit the granting of authorities that would enable SELECT access to T1 (that, in turn, could mean sharply restricting the granting of SYSADM authority, and relying more – for DBAs – on the granting of system DBADM authority WITHOUT DATAACCESS). Additionally, organizations should consider restricting the ability to grant Db2 data-access privileges to IDs that have explicit SECADM authority (versus the implicit SECADM authority that can be associated with SYSADM authority). This restriction of Db2 privilege and authority granting capability can be implemented by setting the Db2 configuration parameter (i.e., ZPARM parameter)
SEPARATE_SECURITY to YES.

• Sharply limit the number of IDs that can create tables in the Db2 system. True, the “hacking” join described by Emil could be accomplished via a recursive SQL statement referencing SYSDUMMY1, but sharply restricting the privileges/authorities needed to create a table would help to limit the possibility of the unauthorized access via join from being accomplished using a table created for that purpose (more on a defense against the SYSDUMMY1 approach can be found below).

• Use the Db2 resource limit facility (RLF) to help prevent a “brute force” execution of the access-via-join approach. In many cases (involving, for example, account numbers, credit card numbers or government-issued ID values), the number of possible values for the masked column could be very large. Especially if the recursive SQL/SYSDUMMY1 approach is attempted, the CPU cost could be a good bit higher than that normally needed for legitimate access to data values. An RLF-imposed CPU time limit could help to preclude that possibility. And starting with Db2 12 for z/OS the resource limit facility can be used for static as well as dynamic SQL statements.

• Audit data access by IDs that have SELECT access to T1. With the number of IDs that have the SELECT privilege on T1 or an authorization that would allow this access appropriately restricted, the “threat area” would be reasonably small. A Db2 audit policy defined for access to T1 could help to ensure that an ID attempting unauthorized access to T1 could be identified relatively quickly. Yes, auditing is an after-the-fact countermeasure, but a person in the small group that could access T1, knowing that they were “being watched” with regard to accessing the table, would have to weigh whether the benefit of accessing values in the masked column would be worth losing one’s job, which would be the likely result of a discovered unauthorized access to T1.

• Follow the comprehensive set of Db2 for z/OS data security best practices documented in the CIS Db2 13 for z/OS Benchmark [Note: on the web page associated with this link, scroll down to the box labeled “IBM Z System.” In that box, click on the downward-pointing arrow on the right side of the box. In the resulting list of benchmark documents, locate the entry for “CIS IBM Db2 13 for z/OS Benchmark v1.0.0,” and click on the orange box, labeled “Download PDF,” for that entry.]

Conclusion

With regard to Db2 for z/OS data security, it’s not about doing A or B; rather, it’s about doing A and B (and C and D and…). As Emil highlighted in his article, Db2 column mask functionality, while definitely a useful means of masking sensitive data values, is not, by itself, a Db2 data protection panacea. Think of Db2’s column mask feature in this light: the more difficult you make the task of unauthorized access to Db2 for z/OS data, the better for data security. Db2 column masks can be an important part of that “make it more difficult” layered security strategy.

References

• IBM Db2 for z/OS documentation – security overview
• IBM Db2 for z/OS documentation – column masks (and row permissions)
• Robert’s Db2 blog – overview of column masks (and row permissions)
• Robert’s Db2 blog – assessing Db2 for z/OS data security (Part 1 and Part 2)