Privileged user controls

Abuse of system access/privileges involves specifically the misuse of bestowed and business justified access to information and systems for unjustified reasons. Once initiated, this abuse can result in an attempt to sell the information for financial gain, a threat of releasing the information in an extortion attempt, or to just inflict damage for various gains. One of the worst aspects of privilege abuse is that while numerous anecdotal examples exist, many others will likely never be discovered.

To ensure the continued health and well-being of any database management system (DBMS), including DB2 and IMS on z/OS, many activities must be performed on a regular basis by system and database administrators. Although these activities can be well controlled by external security processes such as RACF, they are pervasive in effect and can be used in ways that are contrary to security policies.

To cite one possible scenario, suppose there is sensitive data residing on a DB2 table, and the applications that access this table, such as IMS or CICS, are well protected by RACF. The database administrator does not have RACF authority to execute the CICS application, but has database administration authority (DBADM) to administer the table. The database administrator runs an UNLOAD utility against the table, extracting all of the data contained in the table. He or she can then transfer that data through any number of mechanisms to an outside media (FTP, Flash/USB, CSV to spreadsheet, and so on). Because the user has special privileges against the table, there will be no evidence of a security violation that would be reported by RACF.

If, conversely, the environment were protected by an auditing solution, there could be

mechanisms that would report on this authorized, but questionable, use of special privileges. A best practice for audit collection is to monitor any SQL or utility access for privileged users. Conversely, you might elect to monitor each utility event or combine looking for one or both classes of events within a time interval. So, although it might be acceptable for the database administrator to access the audited tables during normal business hours, auditing parameters might be set up to look for unusual access patterns outside of normal business hours. The conundrum is that the nature of these authorities gives the privileged user capabilities to access DB2 and IMS resources and data by means outside the use of the well-protected application environment. This situation has the effect of providing unlimited access to the data from any interface, batch, local, remote, trusted connection, and so on, all the time, thereby circumventing normal transaction-level RACF protection. In a DBMS environment where privileged user authorities have been granted, there must be some mechanism to track and record activities that are performed under the control of these privileged user identifiers. DB2 10 introduces the concepts of separation of duties and least privilege to address these needs. Separation of duties provides the ability for administrative authorities to be divided across individuals without overlapping responsibilities, so that one user does not possess unlimited authority (for example, SYSADM).

In DB2 10, the SYSTEM DBADM authority allows an administrator to manage all databases in a DB2 subsystem. By default, the SYSTEM DBADM has all the privileges of the

DATAACCESS and ACCESSCTRL authorities.

The SECADM authority provides the ability to manage access to tables in DB2 while not holding the privilege to create, alter, drop, or access a table. Furthermore, a DATAACCESS authority can access all user tables without being able to manage security or database objects.

You can use these authorities to minimize the need for the SYSADM authority in day-to-day operations by delegating security administration, system related database administration, and database access duties to the SECADM, SYSTEM DBADM, and DATAACCESS authorities. To go even further, you can separate security administration from the SYSADM authority so that SYSADM can no longer perform security-related tasks.

In addition, in earlier releases of DB2, revocation of administrative privileges granted to specific users triggered a DBMS characteristic referred to as

cascade revocation

. With the use of DB2 native grant/revoke security, the object owner (known as the

grantor

) will in turn grant access privileges to others (known as

grantees

), either to individual IDs, or to RACF controlled group IDs. Based on a change in the privilege grantor business role, some examples might include termination, change in job responsibility, or another event. The desired goal is to remove their access from the security system, and to revoke any administration privileges bestowed on the privilege grantee. However, when the

administrative privilege is revoked from the grantor, now known as the

revokee

, privileges granted to others by the revokee are also subject to revocation. This characteristic of cascading revocation of granted privileges is referred to as

cascade revocation

or

cascade

revoke

. Because it can be difficult to determine the impact of revocation in large and complex DB2 environments, many installations will simply leave the administration privilege intact, even it the individual is no longer employed. As a result, mature DB2 installations can contain a proliferation of many administrative IDs, with powerful levels of administration authorities, but without any real ongoing business need to exist. As we will discover, DB2 10 provides new system controls that can influence how the revoke mechanism handles cascade revocation. Privileged users typically need a means of moving data after they have stolen it. Some use corporate or personal email to send it to external parties or accounts. Some smuggle it out on various types of personal devices or media. Others use approved devices, but for unapproved purposes or in an inappropriate manner. While many organizations view control of the avenue of data distribution as a solution, some examples are removal of USB port connections on workstations, restriction on the use of FTP agents, and so on. it is generally easier to control data at the source. The really important message is one of quickly de-provisioning user access and privileges when they are no longer needed. A good rule of thumb is that if you are no longer sending them a paycheck, then do not leave their administration IDs defined in your database systems.

Another issue with privileged user activities on DB2 for z/OS involves the use and control of audit event collection mechanisms. For many customers, DB2 auditing will include the use of the Instrumentation Facility Interface (IFI) audit trace mechanism. This mechanism is

controlled by the DB2 Trace facility, which requires special administration privileges. However, in most implementations of an IFI based auditing approach, these trace controls and

associated privileges have been granted to the DB2 System Administrators and Database Administration personnel. Indeed, for many customers, these privileged users are tasked with the collection of audit data and the generation of audit reports, the same reports that are then used to verify and report on the activities of these privileged administration users. When DBMS auditing has been implemented in such a manner, it becomes problematic from a separation of roles and responsibilities perspective.

Any mechanism used to audit activities of trusted users must be implemented in such a way as to prevent the privileged user from interfering with the collection of, or contaminating the source of, the audit data. Audit mechanisms against data servers for z/OS must maintain the necessary separation of duties, resulting in assurance of audit data integrity and more accurate reports. These mechanisms allow database administrators to perform their own job duties and allows auditors to run audit reports independently of the database administrators, which results in easier and more accurate audits.

Auditors need to have the ability to adhere to published industry standards and external auditing without relying on the assistance of the personnel being monitored. We will discuss changes with DB2 10 on z/OS that can separate audit event collection controls from

privileged database administrators, which can help demonstrate a strengthened roles separation with audit reporting.

In document Security Functions of IBM DB2 10 for z/os (Page 52-54)