Almost all mainframe / MVS sites today use IBM’s DB2 database system for holding and access to critical business data. Many companies using smaller (e.g. Windows based) servers to provide internal or external (Internet based) access to data use DB2 as the back-end data management system for performance and resilience. Such implementations also provide for much improved security versus storing critical data on smaller and generally weaker systems.

Until recently the security in DB2 has been managed by the DBA using the built-in GRANT / REVOKE mechanisms. A very small number of sites running ACF2 have used the separate ACF2/DB2 feature for externalising the security. With recent versions of DB2 the security can be managed via any external security product (e.g. RACF). Very few sites have yet made use of this possibility, almost all are dependent on the difficult to manage, and almost impossible to audit, internal security.

DB2 Security Review Description

To carry out a mapping and analysis of the current production DB2 internal security environment and its implementation from an authorisation viewpoint of the distributed rights, weaknesses and potential threats.

The following aspects are examined:

Integrity and authorisation

• How does the autherisation structure appear?
• Does information appear to be more widely accessible than would be expected?
• On which ways might authority be distributed in an uncontrolled way?
• Are the indications that the environment is generally under a good level of control?
• What access and “backdoors“ in to the databases can be identified and what rights or RACF profile is needed for any such access?  Who might have such access available? Which information might be manipulated this way?
• How well are functional  authorities utilised in DB2 rather than individual?
   

Traceability

• Are appropriate system logs maintained in respect of activities carried out?
• Are such logs appropriately protected against loss or tampering?
• Is any process in place for investigation / review based on these logs?

Limitations

• The analysis does not (normally) include development or testing DB2 environments though these can be included f required
• Due to the number of DB2 databases and tables held at most sites the client should identify in advance a most critical sub-set of the environment (i.e. projects or applications) of interest for the review. It is normally assumed that the DB2 naming standards will allow for a reasonable selection of the chosen databases/tables
• This analysis will not cover manual routines for the administration of authorities etc.
   

Technique

1. The IBM RACF utility IRRDBU00 will be used to unload the RACF database as a sequential file. This process may be carried out in advance by a clients RACF technician.
   From this file the required  RACF records will be  extracted and reformatted using a specially written assembler program. This program will extract data relating to all  Group profiles, all User profiles, DB2 relevant Dataset profiles,  DB2 DSNR profiles and Started Task profiles.
    
2. DB2 authorisations will be extracted from the DB2 control tables using batch SQL jobs.
   The resulting bulky SQL listings are reformatted and condensed using a specially written assembler program. This also produces some initial exception listings and statistics.
    
3. The above files containing the data extracted from both RACF and DB2 will be downloaded from the mainframe and transferred to a PC for further analysis and comparison. The actual transfer mechanism used will depend on local facilities, a  CD or DVD is frequently be the simplest method.
    
4. The downloaded files will be compared and analysed in detail using programs written specially for this purpose.
   Outline descriptions of the seven special programs and the layouts of the files transferred from mainframe to PC can be provided as part of the completed review documentation if required.
    
5. No business/application data is downloaded, used or taken offsite at any time, only the above mentioned RACF and DB2 control information is used during the investigation. All data, reports etc.  stored on the PC will be AES encrypted at all times.
    

Requirements:

In order that the on-site work be completed efficiently and within the projected timescale it is preferable that the following facilities and authorities should be arranged in advance.

• A suitable work place with a terminal/PC which can be used to connect to TSO, batch and DB2 on the relevant z/OS system.
• Ability to store, process and print locally both TSO datasets and PC type data.
  Ability to transfer files between the mainframe and the PC.
• A RACF TSO userid with normal TSO authorities plus the RACF ‘SYSTEM AUDITOR’ authority.
• The above userid will also require:
• READ access to many system datasets and DB2 software libraries
• Access to the DB2 system databases (not the business databases) and ‘SELECT’ authority on all the ‘SYSIBM’ tables
• Authority to connect to the relevant DB2 region via the DSNR ‘BATCH’ profile
• If RACF  CLASS(PROGRAM) is active then batch execution for the following programs will need to be authorised if these are controlled
    -  IRRDBU00,  IKJEFT01, the assembler and binder (linkage editor)
    -  possibly DB2 program DSNTEP2

Top of page